How does AI fraud detection actually work, once it is inside a bank's own controls? Not as a black box that scores a loan and moves on, but as a division of labour that mirrors what a careful underwriter would do after the fact: re-read the file, link it to its neighbours, trace the rule that admitted it, check the bank's own onboarding, and write up the case. In Early Payment Default Review that work is split across six specialist agents, each with a written list of things it may never do — never contact a borrower, never block an account, never change a rule — and every conclusion waits on a person. The limits are not a disclaimer; they are the architecture.
The run below is the solution's fictional sample vintage at the invented Lanternfield Bank — 87 early defaults, re-read in one pass, used here to show the mechanism step by step. The regulatory context comes from the banking agencies' model-risk guidance, NIST's AI Risk Management Framework and a 2025 GAO study, linked where they appear.
One sample run: six agents, 87 files, and the shape of the hour
1:52
for all six agents to re-read the 87 early-default files of the August vintage — a demonstrated capability on sample data, not a promised processing time
6
specialist agents, each with a written list of things it may never do
87
proposed causes, one per loan, each with its evidence and its runner-up — every one waiting on a person to confirm
How does AI fraud detection actually work, step by step?
Strip the label off and the mechanism is plain: software does the reading, people do the deciding. The loop on one early default runs like this. The monitor agent opens a case the day a loan crosses the early-default line the bank configured, with the file already assembled — application, documents, verification results, decision record, fraud checks, channel, every payment attempt. The re-reader agent reads that file the way an underwriter would, after the fact, and lists every discrepancy it can cite: income, employer, identity, account, address, and the underwriting exception the loan went through. The link analyst reads the loan against 180 days of other applications. The rule tracer replays the decision under the policy version in force at funding and the one before. The onboarding checker reads the bank's own side of the file — what the borrower chose versus what was actually set up. The cause and fix writer proposes one cause per loan, with its confidence, its runner-up and the evidence, groups loans into patterns, and drafts each fix for its owner. Then the loop closes on a person: the analyst confirms or changes every cause.
The re-read in flight: six agents, 87 files, progress you can watch

The six agents: what each reads, and what each may never do
The limits are quoted from the product's own agent list, verbatim, because in this design they carry the weight. The early default monitor watches servicing and opens a case on the configured definition — and never contacts a borrower. The file re-reader lists discrepancies and never calls a borrower a fraudster; it reports signals, and every discrepancy cites its document. The link analyst finds rings and never blocks an account, declines an application or files a report. The credit rule tracer names the rule whose change made the difference and never changes a rule; every proposal goes through fair-lending review. The onboarding checker reports where the bank, not the borrower, broke a step, and never waives a fee or changes credit reporting on its own. The cause and fix writer proposes one cause per loan and never confirms a cause, never sends a fix without the analyst.
The limits matrix: six agents, and the line each one may not cross
Early default monitor
Servicing; opens a case the day a loan crosses the configured early-default line, file assembled
Contacts a borrower, or opens a case on any line but the one in Settings
File re-reader
The application, documents and verification, as an underwriter would after the fact
Calls a borrower a fraudster — it reports signals, each citing its document
Link analyst
180 days of applications and loans, by device, account, phone, address, employer and template
Blocks an account, declines an application, files a report — it prepares the referral
Credit rule tracer
Each decision under the policy version at funding and the one before; the whole vintage under any proposal
Changes a rule; a proposal moves without fair-lending review
Onboarding checker
What the borrower chose versus what was set up: autopay, first due date, letters, statements, payment attempts
Waives a fee or changes credit reporting on its own
Cause and fix writer
All of the above; proposes one cause per loan with confidence, runner-up and evidence; drafts fixes and the report
Confirms a cause; sends a fix without the analyst
Why the file re-reader cannot call a loan “fraud” on its own
Because a signal is not a verdict, and the cost of confusing them lands on borrowers. The re-reader's output is a list — income stated above what deposits show, an employer phone that is an internet line, a pay stub matching others — each item cited to its document. Those signals propose fraud; they do not establish it, and the file itself usually admits an innocent reading for each one. So the product draws the line in the agent's definition: it never calls a borrower a fraudster. It reports signals, and the cause writer may propose fraud as the cause with a confidence and a runner-up, and the analyst — a person who can be asked why — confirms or changes it. The GAO's 2025 study of AI in financial services records why banks care about the distinction: AI "can help combat synthetic identity fraud by identifying cases that human analysts cannot easily detect" (GAO-25-107197, May 2025) — and the same report notes that AI may "reduce false positives, which constitute the vast majority of money laundering and terrorist financing alerts". Detection and false alarms are the same dial; keeping a person on the verdict is how a bank tunes it without guessing.
How the link analyst searches 180 days of applications without deciding anything
The link analyst's work is breadth without authority. It reads the last 180 days of applications and loans on six signals — device, bank account, phone, address, employer, document template — and outputs groups: these 19 loans share 4 devices, 3 receiving accounts and one pay-stub template. What it does not output is an action. It never blocks an account or declines an application; the two pipeline applications carrying the ring's signals get a hold recommendation and a button, and the fraud strategy manager decides. It never files a report; confirmed rings go to the bank's own BSA team, which owns the filing decision and its clock. The design reason is accountability: blocking, declining and filing are acts with legal consequences for identifiable officers, and the system is built so those acts always trace to a named person. How that ring was actually found, signal by signal, is followed through on its own page.
Why the credit rule tracer never changes a rule
A rule change is a credit decision with fair-lending consequences, so the product keeps it where regulation expects it: with people. The tracer's job is arithmetic — replay each decision under the policy version in force at funding and the one before, name the rule whose change made the difference, and replay the whole vintage under any proposed setting. In the sample vintage it names CP-26-07, the July change that lifted the debt-to-income cap for scores 640–679 from 40% to 45%, and shows that 21 early defaults were approved only under the new line; the what-if under a 42% cap with a $1,800 residual-income floor declines 268 of 412 loans and avoids 17 of the 21. What happens next is committee work: the credit policy manager proposes, fair-lending review tests for disparate impact, and the committee decides. The tracer's never-line — never changes a rule — is what lets its arithmetic be trusted as neutral evidence in that room.
What model risk management expects of a system like this
For a decade the banking agencies' model-risk expectations ran through SR letter 11-7; in April 2026 the Board of Governors, the OCC and the FDIC issued revised guidance, SR 26-2, which "supersedes and replaces" both SR 11-7 and the 2021 BSA/AML model-risk statement (SR 26-2, April 17, 2026). In its own words, its principles "apply to traditional statistical and quantitative models and non-generative, non-agentic AI models." NIST's AI Risk Management Framework, which predates it and runs wider, states the human-side principle plainly: "Human roles and responsibilities in decision making and overseeing AI systems need to be clearly defined and differentiated. Human-AI configurations can span from fully autonomous to fully manual" (NIST AI RMF 1.0, January 2023). A six-agent review system is a human-AI configuration of a specific kind — autonomous in reading, manual in deciding — and the way to govern it is to write that configuration down, role by role, which is what the limits matrix is.
“Generative AI and agentic AI models are novel and rapidly evolving. As such, they are not within the scope of this guidance. Nonetheless, a banking organization’s risk management and governance practices should guide the determination of appropriate governance and controls for any tools, processes, or systems not covered in this document.”
the banking agencies’ own words, SR 26-2 (April 2026)
Why “agentic AI” sits outside most banks' current model-risk guidance — and why that is not a free pass
The quotation above is the honest state of the rulebook: the 2026 revised model-risk guidance explicitly does not cover generative or agentic AI, while insisting that a bank's existing "risk management and governance practices should guide the determination of appropriate governance and controls" for whatever sits outside the letter of the guidance (SR 26-2). Read one way, that is relief; read the only way that survives an examiner, it is an assignment. Nothing about agentic AI exempts a bank from knowing what its system did, why, and who decided; the guidance simply declines to prescribe the shape. The practical consequence is that the governance evidence has to be assembled from what the system already records — the proposal, the evidence cited, the confidence, the person who confirmed, the rule version applied — which is exactly the audit trail this solution writes at every step. A bank evaluating any agentic tool should ask for that trail first; how to test one before you trust it takes up the measurement side.
What the agent proposes vs what the person decides, on one file
The agents propose: Fraud, ring R-0926, 96% confidence, runner-up credit 3%.
The people decide: Confirm or change it — the analyst reads the evidence, not the percentage.
The agents propose: 19 loans linked on 4 devices, 3 accounts, 1 template, plus 2 pipeline applications.
The people decide: Pause the sub-source, hold the applications, refer to the BSA team.
The agents propose: CP-26-07 admitted 21 of the early defaults; a 42% cap avoids 17.
The people decide: Propose the amendment, run fair-lending review, take it to committee.
The agents propose: Onboarding broken: autopay chosen, never stored, no payment attempted by the bank’s side.
The people decide: Re-enrol, waive the fee, correct the late mark with the bureaus.
The agents propose: A draft report: the rate, the causes, the fixes and their owners.
The people decide: Sign it, or send it back — the director’s name ends the relay.
What a human still has to confirm, every time
The confirmation list is short and absolute. Every cause — confirmed or changed by the analyst, with bulk confirmation only above the confidence threshold the bank configured. Every hold, pause and referral — the fraud strategy manager's calls. Every rule proposal — the policy manager's, after fair-lending review. Every correction to a borrower's file — servicing's, including the fee waiver and the bureau correction, which the onboarding checker may only recommend. And the monthly report — the director's signature, on a document the cause and fix writer drafted but a person sent. The system's bet is that this list, not the agents' accuracy, is what makes the output usable: an early-default cause that a named analyst confirmed on cited evidence is something a committee can act on, an examiner can sample, and a court can be shown. NIST's framework names the configuration precisely — AI "can autonomously make decisions, defer decision making to a human expert, or be used by a human decision maker as an additional opinion" (NIST AI RMF 1.0) — and this solution is built to stay in the second of those configurations on purpose.
One file through the loop: where the person steps are
Agent
MonitorOpens the case on the configured early-default line; the file is assembled.
Never: contacts a borrower
Agent
Re-reader · link analyst · rule tracer · onboarding checkerRead the file, its neighbours, its rule history and the bank’s own set-up; cite everything.
Never: verdict, block, decline, file or change
Agent
Cause and fix writerProposes one cause with confidence, runner-up and evidence; groups patterns; drafts the fix.
Never: confirms a cause or sends a fix
A person decides
The analystConfirms or changes every cause; sends each fix to its owner.
A person decides
The owners and the directorAccept fixes, sign the report — the month closes on a name.
The loop’s output: the tree after the re-read, patterns first

The thread the sample run surfaces is the one worth carrying out of this guide: the income-verification waiver ran through all three problems at once — 19 ring loans, 9 first-party frauds and 8 credit misses went through the same instant-decision path. An agentic system that only scored loans would never see a pattern like that, because the pattern lives in the exceptions, not the scores. What that exception costs when it stays open is measured in what an unexplained early default costs a bank, and the people who confirm the causes are introduced seat by seat in what a credit risk analyst does when a vintage goes bad. To watch the six agents run on a working vintage, start from Early Payment Default Review.
Questions people ask
How does AI fraud detection work?
As a division of labour: software reads the files — re-reading them like an underwriter, linking them across months, replaying the rules that admitted them — and proposes causes with cited evidence; people confirm every cause and make every consequential call. The limits on what the software may never do are written into its definition.
How does AI anomaly detection work in lending?
By comparing a file against patterns rather than thresholds: a device on several applications, a pay-stub template shared across employers, an account opened days before applying. Each anomaly is a signal with a citation, not a verdict — the verdict stays with a person, because each signal alone has an innocent reading.
How do banks detect fraud today?
Mostly at origination — fraud scores, device intelligence, verification checks — and in sampling after the fact. What early defaults add is a rear-view mirror that works on every file: the loans already went bad, so the signals in their files can be re-read and linked without guessing who will pay.
Is it safe to let AI review loans?
It is safe in the same way a junior analyst's memo is safe: useful, fast, and never the decision. The safeguards that make it so are structural — every claim cites its evidence, every cause waits on a named person's confirmation, and every consequential act (blocking, declining, filing, changing a rule, correcting a bureau mark) belongs to a person by design.
Can AI decide a loan is fraud?
Not in this system. An agent proposes fraud as a cause with a confidence and a runner-up; a credit risk analyst confirms or changes it. The agent's own definition forbids it from calling a borrower a fraudster — it reports signals, each cited to its document.
What is multi-agent fraud detection?
An architecture where different agents do different reads — one the file, one the links across 180 days, one the rule history, one the bank's own onboarding — and a writer agent assembles their findings into one proposed cause per loan. The sample run in this guide is one: six agents, six written limits, one human confirmer.