Mule account detection means finding the accounts that receive and pass on fraud proceeds, quickly enough to stop the money and carefully enough not to freeze a genuine customer. AI helps because a mule network is a pattern across many accounts, and a model can join profile, velocity, device and linkage signals into one case while the money is still there. A single-transaction rule sees one payment at a time.
In India the stakes have risen. The Reserve Bank of India already advises banks to monitor transactions meticulously to identify accounts operated as money mules and take appropriate action. A draft standard operating procedure (SOP), published for comment on September 11, 2026, would add a fixed, time-bound procedure for temporary debit holds, capped at 60 days from the hold unless a law enforcement agency or competent authority instructs otherwise. Rules alone will not meet that standard. A fixed threshold can flag a transaction, but it cannot tell a recruited student from a fraud ring's collection account, and it cannot write down why it flagged either one. Detection has to combine signals across accounts and channels, and a person has to own the decisions that affect a customer's money.
This guide is for heads of fraud and fraud operations, with a focus on Indian banks that are building or replacing mule detection. It explains how AI finds mule networks, where machine learning helps and where it does not, and how to keep false positives under control. For India, it works from the RBI's draft KYC Amendment Directions, 2026, the RBI's December 2024 statement on MuleHunter.AI and the Prevention of Money-laundering (Maintenance of Records) Rules, 2005, as they stood on October 15, 2026. The SOP is still a draft, and this is a practical reading of these texts, not legal advice.
Put any mule detection approach, rules, models or both, through six questions before you buy or extend it. A tool that fails the first will miss networks. A tool that fails the third, fourth or fifth will produce holds you cannot defend, and one that fails the sixth leaves the reporting gap the draft makes explicit.
Mule account detection finds the accounts that receive and forward fraud proceeds. AI does it by joining profile, velocity, device and linkage signals across accounts into one case an analyst can review, and in India the RBI's September 2026 draft SOP would add time-bound debit holds capped at 60 days.
A mule account is a bank or payment account used to receive and forward money for someone else, usually the proceeds of fraud. The RBI's draft SOP defines a money mule account as an account used, knowingly or unknowingly, to receive, layer or transfer proceeds of cyber-enabled financial fraud on behalf of another person. The words "knowingly or unknowingly" carry most of the weight in that definition. They bring in the account holder who sold their login for a few thousand rupees, the job seeker who was told they were "processing payments", and the account that was taken over without the owner knowing. Our glossary entry on the money mule account covers the common mule profiles in more detail.
The RBI has described the use of mule accounts as a common method fraudsters use to channel proceeds of frauds. The draft mule paragraph describes criminals who gain illegal access to deposit accounts by recruiting third parties that act as money mules. For how the networks are built and how the money moves through them, see our typology page on money mule networks.
Mule accounts usually sit in layers. A controller recruits or buys the first-layer account, so the person who opened it is often not the person moving the money. A first-layer account receives money straight from a victim, often over UPI or IMPS, and forwards it within minutes or hours. The first-layer account forwards the money to later layers, usually other mule accounts at other banks. Later layers split, recombine and cash out the funds. The first layer is where a bank has the best chance of holding money before it disappears, and also where it is most likely to be dealing with an unwitting customer.
The controller's aim is to keep each account looking ordinary. That means small credits from many senders, transfers spread across accounts and banks, and genuine-looking activity mixed in with the fraud money. Each payment on its own can pass a threshold check. The pattern only shows when you look at the accounts together.
| Term | Meaning in the draft SOP | Why it matters for detection |
|---|---|---|
| Money mule account | An account used, knowingly or unknowingly, to receive, layer or transfer fraud proceeds for another person | Intent is not required, so detection cannot rely on the customer's behaviour looking criminal |
| Suspected money mule transaction | A transaction of ₹1,000 and above, flagged by monitoring systems including AI/ML tools | The trigger is low, so volume and false positives become a design problem |
| Temporary debit hold | A temporary restriction on debits on suspected amounts or an account, pending verification | The hold affects a real customer's money and has fixed timelines |
| Days | Calendar days | Clocks run through weekends and holidays |
Some mule accounts are opened by real people. Others are opened with a synthetic identity: a real identifier, such as an ID or tax number, combined with an invented name, date of birth or address. A synthetic account can sit quietly for months, building an ordinary history, before it starts receiving fraud money. Some of these accounts are later drained through bust-out fraud on credit lines instead, and the warning signs overlap.
Document checks at onboarding often pass a synthetic identity, because each document looks valid on its own. What gives it away is shared detail across customers: the same device, phone number, email or address on accounts that claim to belong to different people. Our guide to detecting synthetic identity fraud in real time covers those identity-layer checks.
AI identifies mule networks by looking at behaviour, money flow and links between accounts at the same time, rather than judging each transaction alone. Mule detection is a relationship problem. One unusual transfer is noise. Ten new accounts that all received money from the same few senders in the same two days, and all paid it on to the same beneficiaries, is a network.
A production system usually combines several kinds of analysis:
The output that matters is not a bare score. It is a risk level for the account, the signals that drove it and the linked accounts behind it, in a form an analyst can check and an examiner can read. Regulated institutions cannot freeze an account or file a report on a score nobody can explain, which is why human sign-off on high-stakes AI decisions stays in the workflow.
Card fraud tools score one event for one cardholder. Mule detection has to score a group: which accounts received money from the same source, which ones passed it on within hours, and which ones share a device or address with an account already flagged. That difference shows up in the data model. A tool built around relationships between accounts will usually give stronger mule signals than a transaction-scoring engine with a network view added later.
When you assess a vendor, ask them to walk through one real mule ring, with the network view and the reason each account was flagged, rather than a feature list.
Mule controllers change their patterns once a threshold becomes known. Rules do not update themselves. A model trained on confirmed outcomes can pick up a shift faster, because it learns from what investigators confirmed rather than from limits written months earlier. It still needs change control, testing and someone accountable for it.
Supervised models learn from labelled history: accounts your investigators confirmed as mules, and accounts they cleared. They work well on mule types you have already seen and can miss a new scheme that looks nothing like past cases.
Unsupervised models group accounts by similar behaviour without labels. They surface unusual clusters for an analyst to look at, which is how new mule patterns get noticed before anyone has written them up.
Most banks use both. The supervised model handles the clearer cases. The unsupervised clusters raise ambiguous groups that need human judgement before any action. Rules stay in the mix for hard limits your policy or regulator requires.
Ask two questions of any model: how many real mule accounts it finds, and how many genuine customers it flags along the way. A model that finds most mules but flags a large share of genuine accounts still floods the queue. Published detection figures usually count the accounts banks found, not all the mules that were active, so treat vendor and industry numbers with care. Our mule account detection statistics explain what those figures measure and what they miss. The only number that settles the question is the one you measure on your own data.
Mule money moves within minutes of arriving. A batch review that runs overnight finds the pattern after the money has gone. Real-time detection means scoring the payment, or at least the account, while there is still time to hold it. In practice that needs account features that are kept up to date continuously, a fallback rule set for when the model cannot score, and a log of every decision with its timestamp for later review.
Most banks add model scoring on top of their existing transaction monitoring rather than replacing it. That works if the model's flags land in the same queues and case screens your analysts already use. A parallel tool that nobody opens does not catch anything, so plan the integration and the analyst training as carefully as the model.
There are two layers to the answer: what the KYC Directions, 2025 already say, and what the draft SOP would add. Both sit on top of the suspicious transaction report (STR) duty under the PML Rules.
The RBI's KYC Directions, 2025 already include instructions on the operation of bank accounts and money mules. The draft's preamble summarises them: banks have been advised to undertake diligence measures, monitor transactions meticulously to identify accounts operated as money mules and take appropriate action.
The STR duty is separate and already in force. Under the PML Rules, a suspicious transaction includes an attempted transaction, whether or not made in cash, that gives rise to a reasonable ground of suspicion that it may involve proceeds of a scheduled offence. The principal officer, on being satisfied that the transaction is suspicious, must furnish the information to FIU-IND promptly. Our STR glossary entry explains the report itself, and our guide to AML software in India covers the wider PMLA and FIU-IND record.
The draft text of the mule paragraph puts the two together. If an account opened and operated is established to be a money mule account and the bank did not file an STR, the bank is deemed not to have complied with the Directions. That sentence turns mule detection from a fraud-loss question into a compliance question.
Key insight: under the draft mule paragraph, a bank that catches a mule account, offboards the customer and never files an STR has a gap an inspector can find. Mule detection has to end in a reporting decision as well as a hold or an exit.
The Supreme Court, in an order dated August 4, 2026, directed the RBI to adopt and circulate an SOP for temporary debit holds on amounts or accounts linked to money-mule activity and cyber-enabled fraud. The RBI published the draft on September 11, 2026 and took comments until October 2, 2026. Final directions will be issued separately after the RBI examines the feedback. When we checked the RBI notifications page on October 15, 2026, no final directions had been issued. As drafted, the directions would take effect from April 1, 2027, or earlier if a bank decides to implement the SOP sooner.
The draft would apply to all commercial banks, including small finance banks, payments banks, regional rural banks and local area banks, and to urban cooperative banks. It would not apply to nodal accounts, pool accounts, escrow accounts or other special-purpose accounts, and it would not change a bank's existing obligations under the PML Act or the KYC Directions.
A suspected money mule transaction, in the draft, is one of ₹1,000 and above. It is flagged by the bank's transaction-monitoring systems, including AI/ML-based tools, on indicators such as being unusual for or disproportionate to the account holder's declared profile, or having linkage to an account already reported as money mule or fraudulent.
The procedure runs on fixed clocks.
| Step | What the bank does | Timeline in the draft |
|---|---|---|
| 1. Hold | Place a temporary debit hold on the suspected transaction, or on the whole account if the account is suspected | Immediately |
| 2. Notify | Tell the account holder the reasons, how to get the hold removed and who to contact | Immediately if digital, otherwise by end of the next day |
| 3. Explanation | Ask the account holder to justify the transaction or account | 20 days from the hold |
| 4. Decide | Remove the hold, or continue it and report to the jurisdictional police via NCRP-CFCFRMS | 10 days after an explanation, or 30 days from the hold if none arrives |
| 5. Follow LEA instruction | Act on a statutory instruction from the police or a competent authority received within 30 days of the reference | Immediately on receipt |
| 6. Release | Remove the hold if no instruction to continue arrives | On the 31st day from the date of reference to the police |
Read as a sequence, a flag leads straight to a hold. The hold triggers a notice to the account holder. The notice opens a 20-day explanation window. The explanation, or the end of the window without one, leads to a decision. A decision to continue the hold leads to a police reference through NCRP-CFCFRMS. A police reference with no instruction to continue ends in release on the 31st day.
The bank places the hold on the suspected transaction or, if the account itself is suspected, on the entire account. Where no explanation arrives, the bank still has to conduct due diligence before it decides. If it continues the hold, it reports to the jurisdictional police authority with reasons and notifies the account holder. The outer limit is 60 days from the date of the hold, absent a contrary instruction from an LEA or competent authority: up to 30 days for the explanation and decision, and up to 30 more after the police reference. In the draft, "days" means calendar days.
The draft lists five things the internal policy must provide for:
The policy must ensure that an account-level hold is applied only as a last resort and in exceptional circumstances. It must also provide for analysis of flagged transactions based on objective parameters aimed at minimising the risk of flagging genuine transactions or accounts.
The bank must keep a centralised MIS with, for every case, the date of the hold and the reasons, all correspondence and notifications to the account holder, references to the police and their orders, and the release or continuation of the hold. Records must be kept for at least 5 years from the hold or, if the account is closed, at least 10 years from closure, and made available for supervisory review. The bank must also apply enhanced monitoring to the account and to other active accounts and relationships of the same holder.
The STR duty does not change. The draft says banks continue to file STRs with FIU-IND under existing instructions and that the SOP does not modify those obligations.
In December 2024, the RBI described MuleHunter.AI, an AI/ML model being piloted by the Reserve Bank Innovation Hub (RBIH), a subsidiary of the RBI. It said a pilot with two large public sector banks had yielded encouraging results and encouraged banks to collaborate with RBIH on the initiative. In May 2026, the Indian Cyber Crime Coordination Centre (I4C) signed an MoU with RBIH to strengthen collaboration on cyber-enabled financial fraud and on curtailing mule accounts. In a social media post, the Home Minister said the move would work by feeding data from I4C's Suspect Registry to the AI-driven fraud detection system.
For a head of fraud, these are inputs. An external model score or a registry match is a strong signal, but the bank still has to decide what to hold, explain the hold to the customer, record its reasons and decide whether to file an STR. None of that moves to RBIH or I4C.
The draft SOP names two indicator families: activity that is unusual for or disproportionate to the account holder's declared profile, and linkage to an account already reported as money mule or fraudulent. Most practical signals fall under one of the two. The list below is practitioner guidance, not an RBI list.
| Signal | What it looks like | Can a single-transaction rule see it? |
|---|---|---|
| Profile mismatch | A student or homemaker account receives many credits from unrelated senders | Partly: a rule sees the amount, not the declared occupation and expected turnover |
| Pass-through velocity | Credits leave the account within minutes, often to a few repeat beneficiaries | Only if the rule looks at in and out together over a time window |
| Fan-in, fan-out | Many small inbound UPI credits, few large outbound transfers or cash withdrawals | No: it needs a view across counterparties |
| Linkage to reported accounts | The account pays or is paid by an account already reported as mule or fraudulent | Only if the reported list is current and joined to the transaction |
| Device and login changes | A new device or SIM, a login from a new location, then a payout | No: login signals sit outside the payment system |
| New or reactivated account | A new account, or a dormant one, suddenly receiving high value | Partly: a rule can check account age, not why the pattern changed |
| Shared identifiers | Several accounts share a device, phone number, email or address | No: it needs entity resolution across customers |
| Victim complaint linkage | A credit matches a complaint on the national cybercrime reporting portal | Only if complaint data reaches the monitoring system |
In a joined view, profile mismatch and pass-through velocity feed the same case. Device and login changes join that case through the customer's session record. Linkage to a reported account joins it through the counterparty. The case then goes to the analyst with every signal attached. Where the credits arrive over UPI, which settles in seconds, the joined case has to be ready before the money moves on.
None of these signals proves that the account holder is complicit. Under the draft definition, they do not need to be. That is why the response has to be proportionate: a hold on the suspected amount first, an account-level hold only in the exceptional cases the policy defines, and an explanation the customer can actually answer.
Most banks start mule detection with rules: a credit count in 24 hours, a value above a limit, an account younger than a set number of days. Rules are fast, explainable and easy to audit, and they belong in the control set. They fall short in five specific places.
A mule network is a pattern across accounts. A rule that evaluates one transaction on one account will miss ten accounts each receiving a few credits from the same group of victims. The draft SOP's own indicator of linkage to an account already reported as mule or fraudulent is a relationship signal, and a single-transaction check cannot evaluate it.
The draft sets the suspected-transaction threshold at ₹1,000 and above. Every legitimate UPI credit above that amount is in scope for the monitoring logic. A rule tuned to catch small first-layer credits will also hold rent, salary splits and family transfers, which is the outcome the draft's requirement for objective parameters is meant to limit.
Device changes, SIM swaps, login location and complaint data usually live in other systems. A payment rule that cannot see a login from a new device five minutes before a payout is missing one of the strongest mule signals there is.
Mule recruiters change patterns when a threshold becomes known. A rule set reviewed quarterly is a quarter behind. Models that learn from confirmed cases can adapt faster, but they need a feedback loop from investigators and change control of their own.
The draft MIS needs the reasons for each hold, the correspondence and the outcome for every case. A rule fires with a code. Someone still has to turn that into a reason the customer can respond to and an inspector can read. If that writing happens by hand, it is the step that slips when volumes spike.
Every false positive is a genuine customer whose money is held, and an analyst's time spent clearing them. With a trigger as low as ₹1,000, the draft SOP makes this a design problem from the start. Four changes do most of the work:
Technology is only half of it. Set thresholds from measured precision and recall, not instinct. Review them on a fixed cadence, retrain models under change control, and record who approved each change. Our comparison of rule-based systems and AI for false positives goes into the trade-offs in more detail.
Alert fatigue sets in when analysts receive more alerts than they can properly investigate. Either case quality drops, as analysts clear alerts faster and miss real mules, or real cases age in the queue until the money is gone. Under the draft SOP, an ageing queue also puts the 10-day and 30-day decision clocks at risk.
You can size the cost with your own numbers: alerts per day, multiplied by the share that turn out to be genuine customers, multiplied by the minutes an analyst spends on each. That gives the analyst hours spent clearing genuine activity every day, before counting the customer complaints that wrongful holds create. The aim is not zero false positives, which no system achieves. It is a queue your team can work properly.
The draft SOP says the bank acts "as soon as" it identifies a suspected transaction or account, through its monitoring system or under its internal policy as approved by its appropriate authority. In our reading, an immediate amount-level hold on a high-confidence flag can be automated if that approved policy says so. Other decisions should stay with named people.
The draft treats account-level holds as a last resort for exceptional circumstances, so a person should approve each one. Removing or continuing a hold after the customer replies, and referring the case to the police, is a judgement about the customer's explanation. The draft gives the bank 10 days to make it after an explanation arrives.
The STR belongs to the principal officer, who decides that a transaction is suspicious and furnishes the report under the PML Rules. Software prepares the case, and the principal officer makes that call.
Complaints need people too. The draft requires nodal officers for complaints arising from the SOP, and resolution within 30 days. A complaint about a wrongful hold needs someone who can read the case and change the outcome.
In practice the flow splits in two. Software applies the amount-level hold where policy allows. For an account-level hold, software sends a recommendation to the fraud operations head, who approves or rejects it. Separately, the case goes to the principal officer, who decides whether to file the STR. The approved STR goes to FIU-IND.
The table below shows a reasonable split. It is our recommendation, not a requirement in the draft.
| Step | Software can | A person decides |
|---|---|---|
| Flag | Score transactions and accounts, join registry and complaint data, show the signals | Which thresholds and models are approved for use |
| Amount-level hold | Apply it immediately where policy allows, and send the notice | Whether policy allows automatic holds, and for which signals |
| Account-level hold | Recommend it with reasons | Whether to place it |
| Explanation review | Gather the explanation, documents and new transactions into the case | Whether the explanation is satisfactory |
| Police reference | Prepare the NCRP-CFCFRMS reference with reasons | Whether to continue the hold and refer |
| STR | Draft the STR from the case | Whether the transaction is suspicious, and approval of the report |
| Release | Track the 31st-day and 60-day limits and prompt the release | Exceptions backed by an LEA or competent-authority instruction |
Illustrative scenario, not a customer result.
On a Tuesday morning, a mid-sized private bank's monitoring flags two savings accounts. The first belongs to a 20-year-old student, opened four months ago, who usually receives about ₹8,000 a month. Over 90 minutes it receives 14 UPI credits between ₹2,000 and ₹9,500 from 14 different senders, and money goes out to two beneficiaries within minutes of each credit. The login that approved the transfers came from a device the account had never used, and one sender's bank has already reported the account on the national cybercrime portal.
The second account belongs to a small shop owner who received 11 UPI credits of ₹1,200 to ₹4,000 that morning and paid ₹30,000 to a supplier at noon. It crosses the same simple velocity rule. A rule-only system holds both accounts. A system that joins signals separates them.
Monitoring and scoring passes flags to the AI agent layer. The AI agent layer hands a prepared case to the fraud analyst. The fraud analyst sends hold and referral recommendations to the fraud operations head. Where the case points to suspicion, the fraud analyst escalates it to the principal officer. The kill switch stops the AI agent layer without stopping the case, and the fraud head holds it.
If you use AI agents, set their authority in writing: which holds they may apply on their own, which they must only recommend, and how to stop them. The agent layer is optional. A bank can run the same split with rules, models and analysts, but the boundaries in the table above should not move.
For the broader detection stack, with rules, models and case management working together, see our guide to fraud detection systems for banks.
Monitoring scores transactions and accounts, an optional AI agent layer prepares the case within limits the bank sets, the fraud analyst investigates and recommends, the fraud operations head or nodal officer approves account-level and continued holds, and the principal officer decides the STR.
| Component | Responsibility | Boundary |
|---|---|---|
| Monitoring and scoring | Score transactions and accounts and join device, login, registry and complaint data. | Does not decide that a customer is a mule. |
| AI agent layer (optional) | Prepare the case: signals, linked accounts, timeline, draft notice, draft police reference and draft STR. | Places no account-level hold, makes no police reference and files nothing on its own; acts only within the autonomy the bank sets and stops when the kill switch is used. |
| Fraud analyst | Investigate, review explanations and recommend holds and referrals. | Works within the internal policy. |
| Fraud operations head or nodal officer | Approve account-level and continued holds and handle complaints. | Accountable for the SOP decisions. |
| Principal officer | Decide that a transaction is suspicious and furnish the STR to FIU-IND. | Owns the reporting decision. |
The fraud operations head or nodal officer decides account-level and continued holds and police references, and the principal officer decides whether a transaction is suspicious and approves every STR. Any AI agent works only within the autonomy the bank sets in its approved policy, files nothing on its own, and the fraud head can switch it off at any time.
Mule account and suspected-transaction definitions, ₹1,000 trigger, hold, notice, 20/10/30-day clocks, 31st-day release, 60-day maximum (30 + 30), internal policy, MIS, retention and supervisory review, STR obligations unchanged, deemed non-compliance where no STR is filed.
Draft for consultation, proposed effective April 1, 2027; not final. Re-fetched 2026-10-15; the RBI notifications page (latest entry October 12, 2026) and press releases (through October 15, 2026) showed no final directions.
2026-10-15
Supreme Court order of August 4, 2026, comment deadline October 2, 2026, final directions to be issued separately.
RBI press release.
2026-10-15
MuleHunter.AI piloted by RBIH, two-bank pilot, banks encouraged to collaborate.
RBI policy statement.
2026-10-15
Definition of suspicious transaction including attempted transactions; principal officer furnishes STR promptly.
Indian subordinate legislation, FIU-IND consolidated copy.
2026-10-15
I4C signed an MoU with RBIH on cyber-enabled fraud and mule accounts; Suspect Registry data to feed AI-driven detection.
Public broadcaster report; PIB original not retrieved.
2026-10-15
Mule activity coverage, baseline comparison, signals behind every score, login and payment signals in one case, people decide high-risk payments, shadow mode, no detection rates quoted from a demo.
FluxForce product page, live 2026-10-15.
2026-10-15
| Metric | Definition | Decision guardrail |
|---|---|---|
| Hold precision | Share of holds that end in continuation, police reference or STR. | Read with the false-hold rate, never alone. |
| False-hold rate | Share of holds released after a satisfactory explanation. | Track by segment, such as students, small merchants and new accounts. |
| Time to first action | Time from the first fraud credit to the hold. | Measured from the credit, not from when an analyst opened the case. |
| Clock compliance | Share of cases decided within the 10-day or 30-day limit and released by day 31 where required. | Count every case, including those closed by complaint. |
| STR linkage | Share of confirmed mule cases with an STR filed. | Should be every confirmed case, given the draft's deemed non-compliance rule. |
Compare tools on what they show you with your own data, not on a feature grid. Five criteria separate them:
Then run it in shadow mode beside your current controls. Count the mule accounts it would have held, the genuine customers it would have spared and how long each case took to assemble.
AI identifies mule networks by joining what single-transaction rules cannot see: behaviour against each account's own baseline, money moving through linked accounts, shared devices and links to reported accounts. Machine learning adapts faster than fixed rules, but it needs feedback, change control and a measured false positive rate to stay useful.
For Indian banks, mule account detection now has two tests. The first is whether you catch the first-layer account while the money is still there. The second, under the draft SOP, is whether you can show the reasons for each hold, meet each clock and file the STR. Joined signals answer the first. A case record that fills as the work happens answers the second. Account-level holds, police references and STRs stay with your fraud head, nodal officer and principal officer.
Test any approach on your own data: which accounts it would have held, which genuine customers it would have spared and how long each case took to assemble. The final SOP may differ from the draft, so review your policy and configuration once the RBI issues it.
Mule account detection is the work of finding accounts that receive and pass on the proceeds of fraud for someone else. In the RBI's draft SOP, a mule account can be used knowingly or unknowingly, so detection has to rely on behaviour and links between accounts rather than on the holder's intent.
It compares each account with its own baseline, maps money flows across accounts, spots money that passes straight through, and links accounts that share devices, details or counterparties with accounts already reported. The result is a case with the signals listed, which an analyst reviews before any account-level action.
Rules usually judge one transaction on one account against a fixed limit. Mule controllers keep each payment small and spread the money across many accounts, so every payment can look ordinary while the pattern across accounts is clear. Rules also cannot see device, login or complaint data held in other systems.
Compare accounts with their own history, resolve customers across accounts before scoring, add counterparty and channel context before an alert fires, and feed analyst decisions back into tuning. Set thresholds from measured precision and recall, and review them on a fixed cadence.
Not yet. It is a draft published on September 11, 2026, with comments closed on October 2, 2026, and no final directions had been issued when we checked on October 15, 2026. As drafted, it would take effect from April 1, 2027, or earlier if a bank chooses to implement it sooner. The existing KYC Directions already advise banks to monitor transactions to identify mule accounts and act.
Up to 60 days from the date of the hold, unless a law enforcement agency or competent authority instructs otherwise. Within that, the customer has 20 days to explain, and the bank must decide within 10 days of an explanation or 30 days from the hold if none arrives. After a police reference, the hold is removed on the 31st day unless an instruction to continue arrives.
Yes. The draft says the SOP does not modify STR obligations to FIU-IND. Its mule paragraph also says a bank that did not file an STR on an established mule account is deemed not to have complied.
Only where your internal policy allows it, and the draft treats account-level holds as a last resort. A sensible design lets agents apply amount-level holds for high-confidence signals under policy, prepare everything else and leave account-level holds, police references and STRs to named people.