Fed fraud classifier model: code claims first, then compare denials

The Fed fraud classifier model, the Federal Reserve's FraudClassifier, is a voluntary scheme for labelling any payment fraud by asking who initiated the payment and how the fraud was executed. Its first split, an authorized party or an unauthorized one, lands almost exactly on the line Regulation E draws for unauthorized transfers, and one of its labels, the false claim, is the industry's first-party fraud on a dispute. It is not a detection tool and not a legal test; its own terms say so. Its use for a disputes team is consistency: code every Reg E claim on the same paths, and you can compare how similar claims were decided and see when denials start to drift. Botminds' First-Party Fraud Detection, software for investigators deciding likely false Reg E claims, compares every proposed denial with similar claims before a person sees it. This guide explains the model and how to put it to that use.

What is the Fed's FraudClassifier model?

It is a classification structure published by the Federal Reserve through its FedPayments Improvement program, built so that fraud is labelled the same way whatever the payment rail. In the Federal Reserve's words, it "was developed to help address the industrywide challenge of inconsistent classifications for fraud", and its key advantage is that it classifies a fraud the same way whatever the payment type or channel. A debit card claim, an ACH claim and a P2P claim can all land on the same path.

It was developed by the Fraud Definitions Industry Work Group, made up of payments fraud experts, and adoption is voluntary. The Federal Reserve offers an interactive walk-through of the paths with a scenario for each, and registration gives access to a downloadable version, the supporting definitions and a classification tool. Among the benefits it lists is one that matters most to a disputes desk: the model "can be applied across an organization to help ensure greater internal consistency in fraud classification, more robust information and better fraud tracking."

The first question is who initiated the payment

Every classification starts with initiation, defined as "the creation of an instruction to transfer funds". The model then asks whether the person who created it was an "individual or entity with the right to initiate the payment" or one without that right. Only after that does it ask how the fraud was executed and by what tactic.

That first split is close to Regulation E's own first question. A transfer is unauthorized under 12 CFR 1005.2(m) when it is initiated by a person other than the consumer without actual authority. An investigator who has answered the classifier's first question from the bank's records has done most of the work the regulation asks for, and has done it in words that do not prejudge the customer.

The two are not identical, and the gap matters. The model treats a payment the account holder initiated after being manipulated, by a romance or impostor scam, as initiated by the authorized party. Regulation E agrees only where the customer sent the money himself. Where a fraudster tricked him into sharing a code and then sent it, the CFPB treats the transfer as an unauthorized EFT, and the classifier puts it on the unauthorized-party side, because the fraudster created the payment instruction.

Where a false claim sits: authorized party acted fraudulently

On the branch for an account holder acting dishonestly. The model defines that method as "Authorized Party initiated the payment with intent to defraud", lists three tactics under it, embezzlement, false claim and synthetic identity, and defines the false claim as "An intentional lie or deception in order to receive a payment or avoid a payment obligation."

The Federal Reserve's own scenario for that path reads like a dispute file. A customer orders goods online, receives them, then calls her bank to report the purchase as fraud, suggesting her credentials were stolen. The model's explanation: "She then intentionally defrauded the bank by claiming she never made that purchase (and lying about the whole situation)." Regulation E's equivalent is the exclusion of a transfer made with fraudulent intent by the consumer, and what Reg E says about friendly fraud takes that clause apart.

Is the FraudClassifier a detection tool or a legal test?

Neither. It labels a fraud once someone has established what happened; it does not find fraud and it does not decide who pays. Its terms are explicit that the model creates no mandate, rule, legal status, liability for loss or reporting duty, and defines nothing in law. Under Regulation E, liability is set by 12 CFR 1005.6 and the burden of proof by the statute, not by a label.

That has two practical consequences. A claim coded "false claim" is a conclusion the investigation must earn; coding it that way at intake, before anyone has read the records, is the shortcut examiners cite. And the model's terms add a condition any vendor should respect: "Absent written consent, the FraudClassifier model may not be used in a manner that suggests the Federal Reserve endorses a third-party product or service." Nothing on this page suggests otherwise; the model is a public vocabulary a bank can adopt on its own.

What is the ScamClassifier, and how does it fit beside the FraudClassifier?

It is the Federal Reserve's companion model for scams, meant to be used before or after the FraudClassifier. It first asks whether a case meets its definition of a scam, deception or manipulation used to achieve financial gain, then whether the scam produced an authorized payment or an unauthorized one, and then sorts it into a category, products and services or relationship and trust, and a type such as bank impostor or romance impostor. Its stated aim is to give "a view of the full impact of scams by including cases that resulted in authorized payments, as well as unauthorized payments from account access."

For a Reg E desk, the ScamClassifier's second question is the important one. A scam that ends with the customer sending money himself is an authorized payment. A scam that ends with the customer handing over a code, and the fraudster sending the money, is an unauthorized payment in which the authorized party enabled access. Those two cases are treated differently under Regulation E, and coding them apart keeps a desk from mistaking a deceived customer for a dishonest one.

Mapping each classifier path to what Regulation E asks

Each path points the investigator at a different Reg E question and a different set of records. The classifier supplies the label; the regulation supplies the consequence. Read together, they tell a desk which claims it must pay within the liability limits, which fall outside the unauthorized-transfer protections, and which it can deny only if it can prove what the customer did.

Coding claims so similar denials can be compared

Give every claim two codes: the path the customer's statement implies, and the path the investigation found. A customer who says "someone got into my account" is claiming an account takeover. If the records show his own device, his own network and no takeover signs, the found path is a false claim. A first-party denial is exactly a claim whose two codes disagree, and a desk that records both can count, compare and audit those disagreements.

Comparison is where the codes pay off. A denial is defensible when similar claims were decided the same way, and the classifier gives a neutral definition of "similar". Take a fictional sample bank as it runs Botminds' First-Party Fraud Detection. Before a proposed denial of a $740.00 P2P claim reached a person, the agents compared it with 38 claims since July with the same pattern: sent from the customer's registered device to a recipient paid five or more times before.

In classifier terms, the seven paid claims had moved off the "own device, known recipient" pattern onto the unauthorized-party side: four had a new device added in the days before, the mark of an account takeover, and three had a reported impostor call or text, the mark of a scam with account access. The claim under review had neither, so a denial treated its customer as the other 31 had been treated.

The comparison the agents run before a person sees a denial

The same morning showed three claims on three paths. One customer's $1,150.00 transfer went out two minutes after she read a one-time code to a caller, from a new device to a new recipient: a scam with account access, proposed for payment. Another's $310.00 online purchase came from a device first seen two minutes before it and shipped to an address not hers: mixed evidence, proposed for payment under the confidence floor. The $740.00 claim was the only one whose records contradicted every statement.

Three claims, three paths, on one investigator's morning

What drift looks like in a month of decisions

Drift is the same kind of claim being decided differently in different places or months. Coded claims make it visible: if denials of "own device, known recipient" P2P claims rise in one program, either the claims changed or the standard did, and only a re-read can tell which. In the sample bank's September review, flagged claims from one fintech partner's customers were denied at 62%, against 45% across programs.

The re-read found that partner's customers reported later than the bank's own, and that one denial, of $164.00, had leaned on reporting time, which the policy forbids; it was reopened for payment. The rate was the signal and the codes made the comparison fair, but the fix came from reading the files. How such a review is built and signed each month is in first party fraud prevention.

The month's comparison, by program and by transfer type

Putting the codes to work on a Reg E desk

Coding is cheap to start and easy to spoil. The two mistakes to avoid are coding too early, before the records are read, and coding too coarsely, so that every dispute becomes "fraud". A desk that adopts the classifier should treat the codes as a by-product of the investigation and review them the way it reviews denials.

Questions people ask

How do banks classify fraud?

Many use their own categories, which is the inconsistency the FraudClassifier was built to address. The model asks who initiated the payment, an authorized or unauthorized party, then how the fraud was executed and by what tactic, and it works the same way for checks, cards, ACH, wires and P2P.

What does "authorized party acted fraudulently" mean?

That the person with the right to make the payment made it intending to defraud. The model lists three tactics under it: embezzlement, a false claim, and synthetic identity, where an account is opened under a fabricated identity.

Does the FraudClassifier decide who carries the loss?

No. Its terms say it does not define or imply liability for losses or create legal definitions. On a consumer claim, Regulation E and the EFTA decide liability, and the bank must show a transfer was authorized before it can deny.

Is the FraudClassifier free to use?

Adoption is voluntary and the model and its definitions are published by the Federal Reserve; registration on FedPayments Improvement gives access to a downloadable version, the supporting definitions and a classification tool. Its terms bar uses that suggest Federal Reserve endorsement of a product without written consent.

Why classify fraud claims consistently?

Because a denial is easier to defend, and drift easier to catch, when similar claims carry the same label. Two codes per claim, the path claimed and the path found, show exactly where a desk is denying, and let a reviewer compare those denials like with like.