Receiver Risk Scoring in Banking: A Practical Framework

Receiver risk scoring changes the question a bank asks before money moves.

Most payment controls begin with the sender: Is the customer authenticated? Is the device familiar? Is the amount unusual? Is this a new payee? Is the customer being manipulated? Those are essential questions, but they do not answer a second one that often decides whether a loss is recoverable: what does the destination account tell us?

A customer can be genuine, authentication can succeed, and the payment can still be headed to a mule account, a compromised legitimate account, a synthetic-identity account, or an account connected to a wider criminal network. The sender may be the victim. The receiver may be the fraud infrastructure.

That is why receiver risk scoring in banking should be understood as a control capability, not a blacklist and not a payee-name check. It is a current, explainable assessment of the destination account, its behavior, its network, and the payment context—used early enough to make a proportionate decision.

This guide explains the practical architecture: what to score, what not to combine, how to turn a signal into a payment action, and how fraud, claims, AML, product, and model-risk teams can make the capability useful without creating unnecessary customer harm.

The Core Idea: Score the Receiver, Then Decide on the Payment

A receiver risk score is not the final answer to whether a payment should proceed. It is one of the inputs to a governed decision.

Persistent receiver-account risk
+ current receiver intelligence
+ sender and session context
+ payment context and rail rules
+ approved bank policy
= payment action

This separation matters. A newly opened receiver account with unusual pass-through activity may deserve heightened attention. But the action should still depend on the payment rail, amount, sender-to-receiver history, urgency, customer warning response, available intervention time, and the strength of the evidence.

The distinction also prevents a common failure: mixing every signal into one opaque score. A persistent receiver risk score should explain the destination account. A payment-time overlay should explain why this specific payment may need a warning, review, hold, or release. Policy should define what each risk combination means operationally.

For a broader introduction to recipient intelligence and confirmation controls, see EdEconomy’s payee verification and recipient intelligence guide. For the account-network side of the problem, see money mule detection in banking.

Why Receiver Risk Matters Now

Receiver-side detection is not new. What has changed is the pressure to make it timely.

The Federal Reserve Financial Services 2026 Risk Officer Report found that mule detection remains heavily manual. Its survey summary reported that 49% of respondents identified mule activity only after a loss, while only 28% reported real-time money-laundering or fraud screening of received transaction activity. The implication is straightforward: an institution can become highly certain about a dangerous receiver after the funds have already dispersed.

Payment infrastructure is also making destination intelligence more operational. The FedNow Network Intelligence API provides participating sending institutions with receiver-account-level data observed over the service to help assess a potential payment. For ACH, Nacha’s Phase 2 credit-monitoring requirement became practically effective on June 22, 2026, reinforcing risk-based monitoring of potentially fraudulent ACH credits by receiving depository financial institutions.

Neither development creates a universal decline score. In fact, FedNow’s Operating Circular restricts Network Intelligence API output to identifying potential transactions for further review; a decision involving an individual must rely on information other than the output. That is an important design principle for every receiver-risk program: network intelligence is governed enrichment, not outsourced judgment.

The objective is not to treat every unfamiliar account as suspicious. It is to recognize meaningful receiver risk early enough to choose the least disruptive effective action.

What a Strong Receiver Score Looks At

A good receiver risk score is built from a small number of distinct feature families. The table below is deliberately broad: the right weights and thresholds are institution-, rail-, and customer-segment-specific.

Signal family	Examples	Why it matters	Guardrail
Account and onboarding profile	Account age, onboarding channel, identity consistency, sudden reactivation, relationship tenure	New, reactivated, or weakly verified accounts can carry different risk than established accounts	New does not mean fraudulent; avoid universal point values
Incoming-payment behavior	Sender count and diversity, inbound velocity, average-versus-current amount, concentration of claim-linked inflows	Mule accounts often show behavior that is not visible from one payment alone	Compare to the account’s segment and expected use
Funds movement	Time from credit to withdrawal or onward transfer, pass-through ratio, cash-out, downstream diversity, balance depletion	Fraud controls lose value when the account empties before a response is possible	Use event time; posting time alone can be misleading
Relationship and graph context	Shared devices, phone numbers, addresses, employers, beneficiaries, counterparties, or short transaction paths	Mule activity is relational; a single account row often hides coordinated behavior	Treat graph proximity as evidence, not guilt by association
Outcomes and external intelligence	Claims, recalls, returns, restrictions, investigations, permitted network information	Confirmed outcomes and fresh intelligence help the score learn from what happened	Respect use restrictions, freshness, provenance, and correction paths
Data confidence	Feature freshness, missing fields, identity resolution quality, rail coverage, source reliability	A score built on stale or incomplete inputs should not be treated like a high-confidence finding	Carry confidence as a first-class decision attribute

The useful question is not “Which feature is strongest?” It is “Which combination of independent signals is sufficient, timely, and explainable for this action?”

Why Graph Signals Add Value

Graphs are valuable because receiver risk is often a relationship problem. A receiver can be linked to other accounts through shared devices, contact details, addresses, beneficiaries, common funding paths, or rapid many-to-one-to-many transfers. These links can reveal coordinated account opening, repeated victim-to-network paths, or downstream dispersal patterns that do not appear in a flat account profile.

That does not require every bank to deploy a graph neural network. Start with practical, explainable features: number of shared attributes, sender diversity, risky-neighbor ratio, short-path distance to confirmed scam-linked accounts, or unusual fan-in and fan-out patterns. Research on heterogeneous transaction graphs supports the value of relationship features, while also reinforcing that results must be validated in the bank’s own population and operating environment.

From Receiver Signal to Payment Action

The same receiver should not automatically trigger the same response for every payment. A mature design separates the persistent account assessment, fresh enrichment, and payment overlay.

Layer	Question it answers	Typical inputs	What it should not do
Persistent receiver risk	How risky is this destination account over time?	Onboarding, account behavior, dispersal, relationships, prior outcomes	Decide a payment without current context
Current receiver enrichment	Has something changed since the base score was calculated?	New claim, new restriction, recent velocity, fresh network signal, account-status change	Replace internal evidence or permitted-use controls
Sender and payment overlay	Why might this particular payment be risky?	New recipient, amount, device, manipulation signals, payment purpose, customer response	Redefine the receiver’s persistent identity
Policy and workflow	What should the institution do now?	Rail, finality, risk band, confidence, operational capacity, customer impact	Hide an action decision inside a model score

This architecture makes actions explainable. A score can be high because of rapid funds-out, linked claims, and shared devices. A payment can be held because the score is high and the customer is sending a first-time instant payment after a failed warning. Those are different facts and should remain distinguishable in audit evidence.

A Practical Action Ladder

Action bands should be calibrated locally, but the operating pattern is consistent.

Risk posture	Typical response	What makes it defensible
Low or well-understood risk	Proceed	Current data is complete; no meaningful adverse receiver or payment-time signals
Moderate uncertainty	Add a contextual warning or confirmation step	The action creates a pause without treating the customer or receiver as fraudulent
Elevated risk with time to intervene	Route for review, require stronger confirmation, or apply a controlled delay where permitted	The case has multiple signals, clear reason codes, and a defined review path
High risk with strong evidence	Hold, restrict, investigate, or use the rail’s permitted exception process	Action is supported by approved policy, reliable evidence, customer-treatment controls, and escalation rules

The goal is not maximal friction. It is the right friction at the right moment. That is especially important for authorized push-payment fraud, where the customer may be authenticated and genuinely initiating the transfer while acting under manipulation.

Payment Rails Change the Design

Receiver-risk concepts travel across rails; features, latency, and available actions do not.

Rail	Receiver-risk emphasis	Primary control window	Design implication
FedNow and RTP	Fresh account status, network intelligence, recipient novelty, current velocity, post-payment funds-out	Before submission and immediately after	Favor low-latency features, clear policy bands, warnings, and rapid receiving-account response. See EdEconomy’s FedNow fraud detection guide.
ACH credits	Inbound-credit monitoring, receiver-account behavior, subsequent movement, returns and recovery workflow	Before and after posting, depending on process	Build risk-based monitoring that reflects the institution’s receiving role, not a one-size-fits-all real-time score.
Wires	New-beneficiary changes, value, business context, callbacks, account validation, downstream dispersal	Before release	Pair receiver intelligence with strong beneficiary-change controls and commercial-payment workflow evidence.
P2P	New aliases, consumer scam context, immediacy, customer familiarity, destination history	Before send	Use understandable warnings and confirmation moments alongside account-level intelligence.
Internal transfers	Full first-party identity, device, and account history; rapid movement to external rails	Throughout the journey	Use internal visibility to test features and detect the handoff from internal movement to external cash-out.

A Receiver-Risk Decision in Practice

The value of the framework is easiest to see in a payment journey rather than in a feature inventory. Consider a customer making a first-time instant payment to a receiver that has no adverse name-match issue but has recently begun receiving payments from many unrelated senders and moving much of the balance out quickly.

The receiving-account signal should not, by itself, label the account as a mule or cause an automatic decline. It should change the quality of the sending bank’s next question. The bank may have only seconds to decide whether to proceed, warn the customer, or send the case to an available review path. The action should reflect the full evidence, not a single unusual fact.

Decision moment	Evidence available	Proportionate response	What the bank learns
Receiver profile	Elevated sender diversity, rapid funds-out, recent reactivation, but no confirmed adverse outcome	Raise the persistent receiver risk band and preserve reason codes	The destination deserves greater scrutiny, not a definitive label
Payment initiation	First-time recipient, unusual amount, familiar device, authenticated customer	Apply the payment overlay; assess whether this combination is outside the customer’s normal pattern	A legitimate sender can still be at risk of manipulation
Customer intervention	Customer receives a specific warning about scams, recipient verification, and irreversibility	Capture acknowledgement, abandonment, correction, or continued intent without suggesting the receiver is proven fraudulent	Warning response is useful context and a customer-protection outcome
Final decision	Receiver signal, payment context, rail finality, data confidence, and policy threshold	Proceed, add friction, route for review, or use a permitted hold or exception process	Decision evidence remains auditable and separable by source
Post-payment learning	Claim, recall, recovery, receiving-account action, and later AML or fraud outcome	Update labels only when outcome maturity and governance rules allow it	The system learns without turning early suspicion into a permanent fact

This pattern is what makes receiver risk valuable. It gives the bank a structured way to connect destination intelligence to a specific decision while preserving customer treatment, explainability, and the possibility that the initial signal was incomplete.

Claims, AML, and Labels: Build the Feedback Loop

Claims and disputes are not merely downstream servicing events. They are receiver-model feedback. When a customer reports a scam, an account takeover, an unauthorized payment, or a wrong-recipient transfer, the institution learns something about the payment, the customer journey, and potentially the destination account. Those facts should be linked carefully rather than collapsed into a single “fraud” label.

Keep separate	Why it matters
Payment initiator and authorization facts	Regulation E and claim outcomes can turn on who initiated the transfer and how access or authority was obtained
Customer manipulation or scam context	A customer may authorize a payment while acting under deception; that is analytically different from account takeover
Claim disposition	Paid, denied, partial, pending, and withdrawn outcomes have different label value
Receiver outcome	A receiver may be complicit, recruited, deceived, compromised, synthetic, scam-linked, legitimate, false positive, or unresolved
Recovery and restriction outcome	These measure timeliness and control effect, not just model accuracy

Fraud and AML teams see different parts of the same story. Fraud teams may see warnings, manipulation, and the original loss. AML teams may see pass-through behavior, multiple senders, layering, related entities, and recurring network patterns. A receiver risk score can help prioritize investigation across those views, but it should not make a SAR decision automatically.

Information sharing also needs disciplined handling. FinCEN’s current section 314(b) materials describe a safe harbor for eligible financial institutions and associations that share information to identify and, where appropriate, report possible terrorist activity or money laundering, including fraud and other specified unlawful activities. Participation, permitted purpose, access controls, registration, SAR confidentiality, and legal review remain essential.

What Public Bank Materials Reveal

Banks do not publish their receiver-score weights or internal mule models, and they should not be expected to. Their public materials are still useful because they show which control layers institutions are willing to describe: account validation, confirmation of changed payment details, behavioral monitoring, network context, and customer intervention.

Public signal	What it usefully demonstrates	Receiver-risk lesson
J.P. Morgan account validation resources	Account status and ownership checks can occur before a payment	Validity is a separate signal from behavioral safety; retain both layers
U.S. Bank’s discussion of AI and fraud controls	Behavioral, identity, network, and intervention controls can work together	A receiver score should fit a layered control architecture, not replace it
HSBC payment pre-validation	Recipient name and account or IBAN verification can be part of the payment journey	Verification is useful before a payment, but it does not establish trustworthiness on its own
Bank of America’s Zelle guidance	Recipient confirmation is a visible customer-protection step	A well-designed confirmation moment can slow an impulsive or manipulated payment without making an unsupported accusation
Lloyds’ real-time fraud-protection announcement	Real-time analysis and tailored interventions are becoming more prominent	Use decision support to improve the timing and relevance of customer intervention

The common thread is not a single model. It is a sequence of complementary decisions: validate the payment details, assess the payment and destination context, intervene where risk is material, and learn from the result.

Build, Test, and Govern the Capability

The strongest implementation plans begin with data and operating evidence—not model complexity.

Stage	Essential work	Exit evidence
Establish the data chain	Normalize receiver IDs; join payments, claims, recalls, restrictions, investigations, and event-time data; document rail coverage	Teams can trace a receiver outcome back to a source payment and identify material blind spots
Prove the baseline	Build explainable rules and descriptive features for account age, velocity, sender diversity, pass-through behavior, and linked outcomes	Reason codes are stable, alert volume fits capacity, and baseline performance is understood
Add analytics selectively	Introduce supervised ranking where labels are mature, anomaly detection for new behavior, and graph features where they add lift	Incremental value is demonstrated against the baseline without unacceptable false restrictions
Integrate and learn	Map risk to actions, warnings, review routes, and governance; return claims and AML outcomes to the score	The bank can show how the capability changes decisions and can distinguish model, policy, data, and operations issues

Model-risk discipline matters even where a bank begins with rules. Maintain a clear purpose statement, feature lineage, reason codes, approved uses, prohibited uses, performance monitoring, override monitoring, customer-impact analysis, and rollback procedures. The current Federal Reserve model-risk guidance emphasizes a risk-based approach tailored to the institution’s model profile, size, complexity, and use.

Data Confidence and Customer Treatment Are Control Features

The fastest way to undermine a receiver-risk program is to treat every score as equally certain. A score calculated from fresh account activity, resolved identity attributes, mature claims outcomes, and permitted network data is different from a score built on a stale feature, partial rail coverage, or an unresolved identity link. Data confidence should travel with the score into decisioning.

That means preserving several timestamps: when the underlying event occurred, when it was ingested, when a feature was calculated, when the score was produced, when the decision was made, and when funds became available. It also means separating what was available before payment release from what arrived later. A model that quietly uses post-payment evidence to justify a pre-payment decision will look better in testing than it can perform in production.

Customer treatment belongs in the same discipline. Monitor false restrictions, complaints, corrections, appeal or review outcomes, warning abandonment, and human overrides. A high receiver-risk score should never make it impossible to correct an account, update bad data, or understand why a payment was interrupted. Good controls prevent loss while maintaining a defensible path for legitimate customers.

What Leadership Should Measure

A receiver-risk program is not successful because its model has an attractive retrospective metric. It is successful if it finds meaningful risk early enough to change an outcome, while avoiding disproportionate harm to legitimate customers.

Measure	What it tells leadership
Receiver-score coverage	Whether eligible payments are actually receiving the control
Pre-release hit rate	Whether meaningful receiver signals are found before release
Funds remaining at first detection	Whether the institution is identifying risk early enough to preserve a recovery option
Confirmed mule or scam-linked conversion	Whether high-priority alerts produce valuable investigative outcomes
High-risk receiver release rate	Whether strong signals are being bypassed, overridden, or discovered too late
False-positive restriction rate	Whether legitimate customers are being harmed and need a correction path
Claim rate by receiver-risk band	Whether score bands remain calibrated after release
Label latency and feature freshness	Whether the control is learning from outcomes and operating on current evidence
Graph-signal contribution	Whether relational features add value beyond account-level behavior
Review conversion and warning response	Whether intervention changes customer or analyst behavior rather than generating noise

These measures should connect to EdEconomy’s Fraud Analytics KPI guide and Fraud KRI framework.

The Shortcuts That Fail

Shortcut	Why it fails	Better approach
Treat receiver risk as a blacklist	Known-risk lists are reactive and miss emerging behavior	Combine confirmed indicators with behavioral, temporal, and relationship evidence
Treat a name match as proof of safety	A matching account can still be compromised or controlled by a mule network	Use payee verification as a separate layer, then assess account behavior and context
Use one score for every rail	Timing, visibility, finality, and intervention options differ	Share concepts but calibrate features, thresholds, and actions by rail
Mix account risk with payment risk	The result becomes hard to explain and govern	Keep the persistent receiver assessment separate from payment-time overlays
Optimize only for AUC	A strong retrospective model can still act after funds are gone	Measure timeliness, funds remaining, customer impact, and operational capacity
Let a high score decide a SAR	Investigation and reporting require governed fact-finding	Use the score to prioritize work, not to replace AML judgment
Publish universal weights	Point values create false precision across different institutions	Use bank-specific calibration, validation, and approved thresholds

[BANK-SPECIFIC CALIBRATION REQUIRED]

EdEconomy Viewpoint

The fraud decision is incomplete if it stops with the sender.

Authentication can show who is using an account. Transaction scoring can show whether a payment is unusual. Customer warnings can create a moment of reconsideration. But those controls do not fully answer where the money is going.

Receiver risk fills that gap when it connects account history, incoming behavior, funds dispersal, network relationships, claims, AML intelligence, external payment-network signals, and payment context. The strongest receiver risk score is not the one with the most features or the most complicated algorithm. It is the one that identifies meaningful risk early enough to improve a payment decision, explains why it did so, avoids unnecessary harm to legitimate customers, and learns from what happens next.

Related EdEconomy Guides

FAQ

What is receiver risk scoring in banking?

Receiver risk scoring in banking estimates the risk presented by a destination account. It can combine account history, incoming-payment behavior, rapid funds-out, network relationships, claims, prior restrictions, and permitted external intelligence to support a payment decision.

How is receiver risk different from payee verification?

Payee verification checks whether a name or account identifier aligns with the intended recipient. Receiver risk evaluates whether the account’s behavior, history, relationships, and current context suggest a meaningful fraud or financial-crime concern. A valid name match does not prove that an account is safe.

Which receiver signals are most useful?

Useful signals commonly include account age and lifecycle changes, sender diversity, inbound velocity, rapid funds-out, pass-through behavior, linked claims, shared attributes, distance to known risky accounts, prior restrictions, and feature freshness. Their value depends on the rail and the institution’s data quality.

Can FedNow Network Intelligence API output be the sole reason to decline a payment?

No. FedNow Operating Circular 8 states that Network Intelligence API output may be used to identify potential transactions for further review. A decision involving an individual must be based on information other than the API output.

What should executives monitor?

Executives should monitor whether receiver risk is identified before funds deplete, along with high-risk release rate, funds remaining at first detection, claim rate by score band, false-positive restriction rate, recovery performance, label latency, and fraud-to-AML feedback time.

Educational note: This article is educational and strategic. It is not legal, regulatory, compliance, financial, or model-validation advice. Banks should apply their own counsel, governance, payment-rail rules, and customer-impact testing.

Receiver Risk Scoring in Banking: Signals, Models, and Pre-Payment Decisions

The Core Idea: Score the Receiver, Then Decide on the Payment

Why Receiver Risk Matters Now