Nacha fraud monitoring: what 'authorized under false pretenses' asks of originators
For most of ACH's history, fraud monitoring meant detecting entries the account holder did not authorize. The rules now reach a harder case: an entry the originator genuinely authorized, having been deceived into doing so.
What does 'authorized under false pretenses' ask of an ACH originator?
To detect a genuine authorisation that was fraudulently induced — a different problem from detecting an unauthorised one. Nacha's rules extended fraud monitoring obligations to originators and third-party senders, and the transactions in scope look, by construction, exactly like legitimate ones.
- The obligation is to establish and implement risk-based processes to identify entries suspected of being unauthorized or authorized under false pretenses. The second clause is the novel one.
- An entry authorized under false pretenses is indistinguishable from a legitimate entry at the file level, because the authorization was genuine.
- Origination-time authorization evidence is the only signal that distinguishes them, and it has to be produced before the batch, not inferred afterwards.
Part of Payment release authorization
What the obligation actually says
Nacha's risk management rule changes extended fraud monitoring responsibilities across the ACH network, reaching originators, third-party service providers and third-party senders alongside originating institutions.
The operative language concerns establishing and implementing risk-based processes and procedures reasonably intended to identify entries suspected of being unauthorized or authorized under false pretenses. The second limb is what changes the engineering problem.
Why false pretenses is structurally harder
Consider what each category looks like in a NACHA-format file.
| Category | What went wrong | Detectable at the file level? |
|---|---|---|
| Unauthorized entry | The account holder never authorized it | Sometimes — anomalous patterns, returns |
| Error | Wrong amount, wrong account, duplicate | Yes — validation and reconciliation |
| Authorized under false pretenses | The originator authorized it, having been deceived | No |
The third row produces a file that is correct in every respect. The company genuinely intended to pay that amount to that account. The deception happened upstream, in an email the ACH file knows nothing about.
This is why detection-based approaches struggle here. There is no anomaly in the payment instruction, because the instruction faithfully reflects a decision a real person made.
Where the signal has to come from
If the file cannot distinguish the cases, the distinguishing information must be captured before the file exists — at the moment the human authorized the payment.
Specifically, three things that today are not recorded in a form anyone can evaluate afterwards:
- What the authorizer was shown. If the beneficiary account was truncated on the approval screen, the authorization cannot have covered it.
- Whether the beneficiary details were new or changed. A change since the previous payment to this payee is the single strongest risk signal available, and it exists in the originator's own system.
- Who authorized, provably. Not which account, which human.
A risk-based process that produces evidence
The rules are risk-based, which means an originator may scale controls to its own exposure. A defensible programme for a corporate originator has four components.
| Component | What it does | Evidence produced |
|---|---|---|
| Payee change detection | Flags entries where beneficiary details differ from the last payment | A flag, and the previous values |
| Total rendering at approval | Shows full account, routing and name on the approval screen | A record of what was displayed |
| Bound authorization | Signature over a canonical statement of the entry's material terms | A verifiable receipt |
| Pre-origination verification | Batch verified against the receipts before file creation | A reconciliation record |
The fourth row is the one that closes the loop. Verifying the batch against the authorization receipts immediately before origination means an entry altered between approval and file creation fails, and an entry with no corresponding authorization is visible.
What to give your ODFI
Originating institutions are themselves under fraud monitoring obligations and will ask what their corporate originators are doing. A documented answer with verifiable artefacts is a materially better conversation than a description of procedures.
A reasonable package: your risk assessment, your payee-change flag rate, your rendering standard, a sample of authorization receipts with the open-source verification tooling, and your pre-origination reconciliation process.
Scoping honestly
An originator sending tens of thousands of entries per file cannot obtain a human signature per entry, and nothing in the rules requires that.
Scope to the entries where false pretenses risk actually concentrates: credit entries to payees that are new, or whose banking details changed, or that exceed a value threshold drawn from your own distribution. For most corporate originators that is a small fraction of volume and the great majority of exposure.
What monitoring can and cannot reach
| Signal | Unauthorised | Induced |
|---|---|---|
| Device and location anomaly | Often present | Absent — the real customer acted |
| Velocity | Sometimes | Rarely |
| Beneficiary novelty | Sometimes | Present — the strongest available |
| Payment purpose mismatch | Rarely captured | Present, if you capture it |
The two right-hand signals that survive are both about the destination and the stated purpose, not about the person. That is where an originator's monitoring budget earns its keep, and it is also why capturing what the payer was shown matters more here than in ordinary fraud.
Objections and honest limits
“We cannot detect intent.” Correct, and the rules do not require mind-reading. They require a monitoring programme proportionate to the risk, which means using the signals that do exist and documenting the ones that do not.
“This is the receiving institution's problem.” Obligations now sit on originators and third-party senders too. Whatever the commercial allocation, the monitoring requirement attaches at your end.
Building a proportionate programme
- Capture the stated purpose at origination. It is the signal most originators do not have and could.
- Score beneficiary novelty, not payer behaviour. The payer is genuine; the destination is what changed.
- Record what the payer was shown. Which converts a disputed narrative into a retrieval.
- Document what you cannot detect. A programme that states its limits is more defensible than one that implies omniscience.
Terms used here
- Originator
- The party initiating an ACH entry. Fraud monitoring obligations now attach here as well as at the receiving institution.
- Credit entry
- A push payment. Induced credit entries are the category where the account holder genuinely authorised the transfer.
- False pretenses
- Authorisation obtained by deception, so the entry is authorised in form and fraudulent in substance.
Frequently asked questions
Do the rules require cryptographic authorization? No. They require risk-based processes reasonably intended to identify suspect entries. The argument here is that origination-time authorization evidence is the only signal that distinguishes false-pretenses entries, not that any specific technology is mandated.
Does this apply to debits or credits? The false pretenses language concerns credit entries — payments the originator sends. Debit fraud has a different structure and a longer-established control set.
What if we originate through a third-party sender? Obligations reach third-party senders and service providers as well. The practical consequence is that your authorization evidence needs to travel with the instruction.
How do we scope this without gating payroll? Scope to new or changed payees and to a value threshold from your own distribution. Recurring payroll to established accounts is not where false pretenses risk sits.
Can monitoring detect induced payments? Not reliably from behaviour, because the real customer acted. Beneficiary novelty and stated purpose are the signals that survive.
Whose obligation is it? Originators and third-party senders as well as receiving institutions, under Nacha's risk management rules.
What should we capture that we probably do not? The stated purpose of the payment at origination, and a record of what the payer was shown.
Where this fits in Manav
Manav renders the payment or change in full, binds the approver's signature to that exact payload, and produces a receipt an insurer, an auditor or a court can verify without calling anyone.