How to Evaluate Fraud Scoring Across Card, ACH, and Wire

Last updated: September 2026

A fraud score is only as good as the customer context behind it. Most institutions buy and tune scoring one payment rail at a time, so the same customer ends up judged against different thresholds, with different information, on different clocks. The useful way to evaluate fraud scoring across card, ACH and wire is to ask whether all three decisions share one customer view, one policy layer the risk team controls, and one testing loop. Per-rail accuracy matters, but it comes second.

TL;DR

• A fraud score estimates how likely a payment is to be fraudulent from the signals the scoring system can see. What it can see is the first thing to evaluate.

• Per-rail stacks form because institutions buy one tool per payment type. The result is duplicate logic, separate thresholds and no signal passing between rails.

• The blind spot sits between rails. Card is often the strongest rail; wire usually carries the least context of its own.

• Five questions separate a score that works across rails from one that only works on its own: customer context, policy ownership, thresholds, explainability, and rules alongside models.

• Test on your own history and on live traffic in shadow mode before you trust a score on a new rail, and measure approvals alongside fraud caught.

What does it mean to evaluate fraud scoring across card, ACH and wire?

A fraud score is an estimate of how likely a payment or account event is to be fraudulent, calculated from the signals the scoring system can see at decision time. Fraud scoring is the practice of producing that estimate and acting on it: approve, decline, hold, or send to review.

Evaluating fraud scoring across card, ACH and wire asks a different question from per-rail accuracy. The question is whether the score on a wire knows what the card and ACH activity said about the same customer. A director of quantitative analysis in enterprise fraud at a large US bank described the gap: "We don't currently have anything that allows signals from various payment types, or even customer risks or some sort of customer features, that would inform a decisioning on one payment type."

So the short answer is to judge four things first: shared customer context, who controls policy, how changes get tested, and whether the reason for a score reaches the analyst. Per-rail performance comes after those.

Why do most banks score each payment rail separately?

Most banks score each rail separately because they bought their fraud tools that way, one payment type at a time, often owned by different teams. The same director put it plainly: "Every payment type has its own decision engine, if you will." Card sits on one platform, ACH and wire on another, check on a third. In the director's words, "it's basically a very fragmented, segregated decisioning type by payment and channel."

A fraud team member at a community bank described the same pattern from a smaller institution: one product for one payment type, another for check fraud, another for card. Each purchase made sense when it was made. Together they form a stack of point tools.

Adding a tool does not always simplify the stack. A fraud technology lead at a large US regional bank described adding a dedicated wire-fraud tool on top of existing rules and ending up with logic that "looks like a duplicate and a lot of maintenance." A confirmed wire fraud still had to be keyed into the system by hand.

Card is often the strongest rail, because the card network supplies real-time monitoring. A fraud lead at a US regional bank called card the rail the team was "pretty darn good on," while push payments initiated from online banking were where the team had almost no visibility to change strategy. The weakness sits between rails.

Where per-rail fraud scores go blind on the same customer

Per-rail fraud scores go blind in three predictable ways: inconsistent thresholds, no shared signal, and different clocks. Each one means the institution judges the same customer differently depending on which way the money is moving.

Inconsistent thresholds

The same risk appetite gets expressed as different cut-offs in different tools, often maintained by different teams. Nobody decided that a customer should face a stricter test on ACH than on card. It happened because two systems were tuned separately.

A chief compliance officer at a prepaid program manager asked a question many risk teams will recognise: "Are we able to do that based in one rule? Or do we have to have five separate rules if we want different thresholds looked at with different scores?"

No shared signal

A card anomaly, a fresh device, or a recent change to account details never informs the ACH or wire decision for that customer. Each engine scores with what it was given. The wire engine does not know what the card engine saw an hour earlier.

Different clocks

Rails run on different schedules. A fraud manager at a US credit union described ACH and checks screened in batches several times a day, wires and online banking monitored in real time, and debits reviewed in an end-of-day batch. The same customer is judged on different information at different moments, and a fraudster moving money across rails can move faster than the slowest of those clocks.

The fraudster sees one journey: the identity, the device, the linked account, the funding pattern, and then the payment. The institution sees fragments. This is also why fraud losses, review cost and approval rate feel like coupled dials, where moving one moves another. Much of that coupling comes from deciding on too little information, and a per-rail score is, by construction, a decision on part of the information.

What each rail needs of its own — and what has to be shared

Each rail has its own timing, data and feedback, and a fraud score has to respect them. What should not differ by rail is what the institution knows about the customer.

Every rail scores well on its own data. What it misses is on the other rails, and that missing context is the part that has to be shared.

Card. Card is often where scoring is most mature, and card fraud prevention usually benefits from network data the other rails lack. The gap is that card context rarely travels to the other rails.

ACH. ACH risk is now a formal obligation as well as a loss problem, and Nacha's 2026 rules require parties to "establish and implement risk-based processes and procedures reasonably intended to identify ACH Entries initiated due to fraud." Phase 1 took effect on 20 March 2026. Phase 2 took effect on 19 June 2026, in practice Monday 22 June because 19 June is a federal holiday, and extended the requirement to all remaining RDFIs and to non-consumer Originators, third-party service providers and third-party senders below the Phase 1 threshold. What the rule asks for is a working capability.

A card vendor does not automatically cover it: a payments company that had assumed its card-fraud vendors would extend to ACH found they did not handle the ACH case well. For the rail-specific detail, see our guide to ACH fraud detection.

Wire. Wire fraud prevention depends more on outside context than any other rail. A technical product owner for fraud and identity platforms at a large US regional bank summed up the problem in a question: "Wire data is so complex, right?" The same buyer described several vendors "doing this in chunks" and wanted it "in one screen." A wire message says little about the customer, so the score depends on what is known about them elsewhere.

Instant payments. FedNow is a real-time gross settlement service that runs around the clock. Under its operating procedures, settlement becomes final at the earlier of when the service records the debit or credit, or when it sends an Advice of Credit message. After that, the sender can only request a return, and the receiving institution decides whether to send the funds back. Instant payment fraud has to be decided before the money moves.

Shared across all rails. Resolved customer identity, device and behaviour history, recent account changes, and relationship-level risk. Much of that context starts at onboarding; what an account-opening fraud stack should capture is its own subject and is not settled here.

Five questions to ask of any fraud score that has to work across rails

These five questions turn the blind spots above into an evaluation. Ask them of your current setup and of any vendor, in this order.

1. Customer context. Can the wire decision read what card and ACH activity said about this customer, at decision time? A score that only sees its own rail will be blind in exactly the ways described above, however accurate it is on that rail.

2. Policy ownership. Can the risk team change a threshold on one rail, or across all of them, without an engineering ticket? If every rule change waits on an engineering release, the release calendar sets the pace of every other improvement.

3. One policy, many thresholds. Can one rule carry segment- and rail-specific thresholds, or does every variation become a new rule? Five rules for one policy means more to maintain and more room for thresholds to drift apart.

4. Explainability. Does the reason for a score reach the analyst working the case? The operational test is whether each decision carries reason codes and attributes the person in the queue can read.

5. Rules and models together. Can deterministic rules sit around model output on every rail? Rules and models answer different questions, and a mature programme runs both, with rules as guardrails around the probabilistic score. When a given decision belongs in a rule and when it belongs in a model is a separate question, and deserves its own treatment.

If you are comparing platforms rather than auditing your own stack, our guide to evaluating fraud detection software covers the wider buying criteria.

How to test a fraud score before you trust it on a new rail

Test a fraud score on your own history first, then on live traffic without letting it decide, then in production. A vendor benchmark tells you how the score did on someone else's customers.

• Backtest on your own outcomes, per rail. Run the score against historical transactions and confirmed fraud on each rail you plan to use it on. A score tuned on card outcomes may behave differently on ACH returns.

• Ask whether shadow mode is real. The chief compliance officer quoted earlier put the question well: "Is that a true shadow mode where we can test rules and see what the impact would be? Or is that essentially a UAT environment where data has to be loaded for us to do any testing?" A true shadow mode scores live traffic alongside the current system without acting on it.

• Make challenger testing cheap. The bank director described the usual process: "we go and manually change the rule and then put it in challenger and then see what happens… it's just a very manual process." The same director noted that model risk management at the bank treats rule strategies as models, so every threshold change needs evidence behind it. Slow, manual testing turns each of those changes into a project.

• Treat tuning as continuous. A risk analyst at a payments company described the loop: find the rules triggering most, add attributes to reduce false positives, test, repeat. The loop runs for as long as the score is in use.

• Measure approvals alongside fraud caught. A false positive also costs revenue: blocking a good customer loses the payment and, past a point, the customer. How to bring false positives down without letting fraud through is a topic in its own right.

Mistakes that make a score look better than it is

• Judging on per-rail accuracy alone, which hides the cross-rail blind spot entirely.

• Trusting a vendor's benchmark instead of your own outcomes.

• Testing in a loaded copy of production data and calling it shadow mode.

• Counting fraud caught without counting good customers declined.

Where Oscilar fits

Oscilar is a unified platform: real-time data fabric, device and behavior intelligence, rules, and case management in one stack, with risk agents native to it. Fraud, credit, onboarding and compliance decisions run on the same unified customer risk profile, and every decision reads from and contributes back to it. The platform keeps a full audit trail per decision with stored reasoning, human-in-the-loop by design.

Evaluation runs as a backtest against your historical alerts followed by shadow mode on the live queue, with a readout at the end. Nacha named Oscilar a Preferred Partner for Account Validation, Fraud Monitoring, and Risk and Fraud Prevention.

What a real-time fraud prevention platform needs beyond scoring is a wider question than this guide covers. To see how cross-rail decisioning works in practice, start with transaction fraud decisioning across payment types. If you would rather walk through your own rails with the team, you can book a walkthrough.

Frequently asked questions

What is fraud scoring?

Fraud scoring is estimating how likely a payment or account event is to be fraudulent, from the signals available at decision time, and using that estimate to approve, decline, hold or review. The score is only as good as the signals behind it. A score that sees one payment rail is judging part of the customer.

Can one fraud score work across card, ACH and wire?

Yes, if it reads from one customer view while respecting each rail's timing and data. Card, ACH, wire and instant payments need different thresholds and decide on different clocks. What should be shared is the customer context: identity, device and behaviour history, recent account changes and relationship-level risk.

Why do separate fraud scores per payment rail create blind spots?

Separate scores cannot see each other. A card anomaly or a new device never reaches the ACH or wire decision for the same customer, thresholds drift apart because different teams tune them, and batch and real-time rails judge the customer at different moments. The fraudster sees one journey while the institution sees fragments.

How should a bank test a fraud score before it goes live on a new rail?

Backtest it against the bank's own historical outcomes on that rail, then run it in true shadow mode on live traffic without acting on it. Compare it against the current system as a challenger and measure approvals as well as fraud caught. Only then let it decide.

What data does a fraud score use?

A fraud score uses the payment itself plus whatever the system knows about the customer. On card, that includes authorisation and network data. On ACH and wire, the payment carries less, so the score depends more on resolved identity, device and behaviour history, and recent account changes.

How can teams reduce false positives without increasing fraud loss?

Give each decision more context rather than simply moving the threshold. Moving a cut-off trades one error for the other, while better customer context helps separate unusual from fraudulent. Then test the change on history and in shadow mode before it touches production.