The PMLA Red Flags Every Customer-Facing Employee Should Recognise

The Prevention of Money Laundering Act, 2002 and the PML (Maintenance of Records) Rules, 2005 place clear obligations on “reporting entities” — and the definition of that term has widened dramatically. It is no longer just banks and NBFCs. It now reaches insurers, stockbrokers and depository participants, payment system operators, and since the 2023 notifications, virtual digital asset service providers along with a range of professionals such as company secretaries and chartered accountants acting in defined capacities. If your organisation is a reporting entity, your compliance obligation does not sit only with the Principal Officer. It sits with every employee who touches a customer, a transaction or an identity document.

The problem is structural. The Principal Officer files the reports and answers to FIU-IND. But the Principal Officer never meets the customer. The signals that a transaction or relationship deserves a second look are visible almost entirely to the front line — and the front line is usually trained on how to complete KYC, not on what the KYC is supposed to catch.

What does the PMLA require of front-line staff?

Front-line staff must verify the customer, notice when a transaction or relationship looks suspicious, and escalate it to the Principal Officer, who reports to FIU-IND. The legal duty sits with the reporting entity, but it is discharged through the people who meet the customer.

Under Section 12 of the PMLA, a reporting entity must maintain records of prescribed transactions, verify the identity of its clients, and furnish information to the Financial Intelligence Unit – India (FIU-IND). The two report types every employee should at least recognise by name are the Cash Transaction Report and the Suspicious Transaction Report.

The Cash Transaction Report (CTR)

A CTR captures cash transactions of more than ten lakh rupees (or its foreign-currency equivalent), whether a single transaction or a series of integrally connected cash transactions that add up to more than that figure within a calendar month. CTRs are threshold-driven and largely mechanical — the amount triggers the report. This is the part most systems handle automatically.

The Suspicious Transaction Report (STR)

An STR is the one that depends on human judgement, and it is the one that matters here. A transaction — or an attempted transaction, whether or not it was completed — must be reported as suspicious when there are reasonable grounds to believe it involves proceeds of crime, appears to have no economic rationale or bona fide purpose, is made in circumstances of unusual complexity, or gives rise to a reasonable suspicion that it may involve the financing of illegal activity.

Two features of the STR regime trip people up. First, there is no monetary threshold. A one-lakh-rupee transaction can require an STR while a fifty-lakh transaction may not. Suspicion, not size, is the trigger. Second, once the entity is satisfied that a transaction is suspicious, the STR must be furnished to FIU-IND promptly — Rule 8(2) of the PML Rules places that duty on the Principal Officer as soon as they are satisfied the transaction is suspicious. The clock starts when suspicion crystallises, and that usually starts with something a front-line employee noticed and escalated.

The software reports the amount. The employee reports the story behind it. A reporting entity that trains only its systems and not its people is monitoring half of its own risk.

What are the PMLA red flags customer-facing employees should know?

They fall into four groups: identity and documentation, transaction pattern, behaviour and profile mismatch, and relationship and context. Any one is a prompt to look closer; a cluster is a reason to escalate.

Red flags are not proof of laundering. They are prompts to look closer and, where warranted, to escalate to the Principal Officer. No single flag is decisive; a cluster of them almost always deserves a second conversation. They fall into four practical groups.

1. Identity and documentation red flags

The customer is reluctant, evasive or unusually irritated when asked for standard KYC. Identity or address documents look altered, freshly issued for no clear reason, or inconsistent with each other. The PAN does not reconcile with the name or the stated business. The customer wants to open a relationship or push a transaction through without completing verification, or offers a plausible reason to defer it “just this once.” Beneficial ownership is obscured — the person in front of you is clearly acting for someone they will not name.

2. Transaction-pattern red flags

The classic pattern is structuring, also called smurfing: deposits or transfers deliberately kept just below the ten-lakh reporting threshold, or a large sum broken into many smaller cash movements across days or accounts. Watch for round-tripping, rapid movement of funds in and straight back out (“pass-through” activity), sudden spikes that do not fit the customer’s history, or a dormant account that abruptly comes alive with high-value flows.

3. Behaviour and profile-mismatch red flags

The transaction does not match the customer. A modest salaried profile moving sums that make no sense for that income. A student account receiving large third-party transfers. A customer who is oddly incurious about returns, fees or risk but intensely focused on speed and on how quickly funds can be withdrawn. Nervousness, over-explanation, or a rehearsed cover story when asked routine questions. Frequent use of third-party payers or receivers with no evident connection to the customer.

4. Relationship and context red flags

The customer, a beneficial owner or a counterparty appears on a sanctions or watch list, or is a politically exposed person whose source of wealth has not been established. The business rationale for the transaction is missing or absurd — goods priced far above or below market, invoices that do not correspond to anything real, cross-border flows to or from jurisdictions with weak controls and no commercial logic. Reluctance to explain the source of funds is itself a flag.

What is tipping off, and why must front-line staff never do it?

Tipping off is telling a customer, directly or by hint, that their transaction has been flagged or reported. It is prohibited because section 12 of the PMLA requires the information furnished to FIU-IND to be kept confidential.

When a front-line employee spots a red flag, the instinct to be helpful can become dangerous. Telling the customer that their transaction has been flagged, delayed for “compliance reasons” or reported is prohibited. The PMLA framework treats an STR as confidential; disclosing to a customer that a report has been or may be filed defeats the entire purpose and exposes both the individual and the entity to serious consequences. The correct move is invisible to the customer: complete or decline the interaction normally, then escalate internally to the Principal Officer through the defined channel. The customer should never learn that a red flag was raised.

Why do front-line PMLA controls fail without training?

Because the people who see red flags first are usually the least trained on what they mean, and are measured on speed rather than escalation.

Reporting entities invest heavily in transaction-monitoring systems and in the Principal Officer function, and then assume the middle is covered. It rarely is. The relationship manager who onboards the customer, the branch or store executive who accepts the cash, the sales agent chasing a target and the KYC processor clearing a backlog are the people who see the red flags first — and they are typically the least trained on what those flags mean or what to do about them. Worse, their incentives often pull the other way: closing the account, hitting the number, clearing the queue. A red flag is friction, and untrained staff are wired to remove friction.

That is why role-based awareness matters more than another policy circular. Structured PMLA and anti-money-laundering training that puts realistic scenarios in front of customer-facing staff — the structured cash deposit, the mismatched profile, the customer who will not name a beneficial owner — builds the pattern recognition that a policy document cannot. It also teaches the two things employees most often get wrong: that suspicion, not amount, drives an STR, and that tipping off is never acceptable. Our prevention of money laundering training hub sets out the options by role. For the broader compliance picture and how enforcement timelines have tightened, our earlier piece on the PMLA deadline your bank isn’t talking about sets the context.

How do you turn red-flag recognition into a habit?

The organisations that get this right do not rely on employees remembering a list. They make recognition and escalation part of the workflow. Three moves do most of the work.

Give every customer-facing role a short, specific red-flag playbook

Not the full AML policy — a one-page, role-relevant set of the signals that particular role will actually encounter, with two or three worked examples. A branch teller, a wealth relationship manager and a crypto onboarding agent see different red flags; their playbooks should differ too.

Make escalation frictionless and safe

Employees escalate when it is easy and when they trust they will not be blamed for a false alarm. A single, well-known internal channel to the Principal Officer, an explicit “when in doubt, raise it” norm, and clear reassurance that raising a flag in good faith is exactly what the organisation wants — these turn awareness into action. A red flag that is noticed but never escalated is worth nothing.

Refresh with real scenarios, not annual slideware

Laundering typologies evolve — mule accounts, virtual digital assets, trade-based schemes. Short, periodic refreshers built around current, India-specific scenarios keep the front line’s pattern recognition current in a way a once-a-year acknowledgement never will.

What is the bottom line for reporting entities?

PMLA compliance is often framed as a reporting problem — the right forms, filed on time, by the right officer. It is really a recognition problem. The forms are only ever as good as the judgement that feeds them, and that judgement lives at the front line. A reporting entity that has excellent systems and a well-run Principal Officer function, but a customer-facing workforce that cannot tell a structured deposit from an ordinary one, is exposed exactly where it can least see it. Training the people who meet the customer is not a nice-to-have layered on top of the technology. It is the part of the control that the technology cannot replace.