Skip to main content
Payment fraud is the risk that a funding payment gets reversed. If a customer has already spent or withdrawn provisional funds by the time the reversal arrives, the business covers the loss. In fintech and crypto, funding fraud typically starts with stolen card or bank credentials, or bank accounts with no real balance. The fraudster deposits funds into an online account, then withdraws them to a wallet or account they control. The victim or their bank eventually disputes or reverses the transaction, clawing the funds back from the business. Card networks call these chargebacks; the ACH network (the primary US bank-to-bank transfer network) calls them returns; other contexts call them disputes. The outcome is the same; the business loses the original amount plus penalties. Unchecked, these losses compound fast. Visa, Mastercard, ACH, and other networks cap the reversal rate a business can sustain. Exceeding that cap means losing access to the network entirely, which cuts off revenue collection. Managing funding risk means blocking bad transactions without blocking good ones. Any risk solution needs to let you tune the filtering thresholds to match your business model and risk appetite.

​
Types of payment fraud

​
Card Fraud

Card funding covers credit and debit card payments for online purchases or wallet top-ups. The core risk is a chargeback, the payment reverses, and the business absorbs the loss. Chargebacks fall into two types:
  • Friendly fraud: the customer authorizes the payment, then disputes it and files a chargeback to force a refund. Also called first-party card fraud.
  • True fraud: a fraudster uses stolen card credentials to fund an account or make a purchase. The legitimate cardholder disputes the transaction. Also called third-party fraud.

​
Bank Fraud

Bank funding covers interbank transfers used for online purchases or wallet deposits. A fraudster with stolen online banking credentials can move funds from the victim’s account onto a platform account and redistribute them.

​
ACH Fraud

ACH (Automated Clearing House) is the primary US interbank transfer network. ACH funding risk falls into two categories:

​
Non-sufficient funds (NSF)

When a bank account lacks the balance to cover a funding request, the bank issues a Non-Sufficient Funds (NSF) return with code R01. ACH transfers take around two business days to settle. If the account runs short before the request reaches the holder’s bank, it triggers an NSF return. The ACH network has no real-time balance check at initiation. Third-party open banking providers fill that gap with a point-of-transaction balance lookup. Even with a balance check, funds can leave the account during the two-day window, so NSF returns remain possible at settlement.

​
Unauthorized Returns

When a fraudster initiates an ACH transfer without the account holder’s authorization, the holder reports it to their bank and the transfer returns as unauthorized. Return codes R05, R07, R10, R11, and R29 all flag this, with R10 being most common. The usual cause is stolen account details.

​
APP fraud

In Authorized Push Payment (APP) fraud, the victim sends the money themselves. A fraudster deceives or coerces them into authorizing a transfer to an account the fraudster controls. Card fraud and unauthorized ACH returns involve transactions the account holder never approved. APP fraud involves a transaction they did approve, which is what makes it hard to catch. APP fraud is most common on real-time networks like the UK’s Faster Payment System (FPS), where funds settle in seconds and are gone once sent. Common typologies: investment scams (high-return promises, often crypto or precious metals), purchase scams (goods never delivered), romance scams (fabricated relationship used to solicit money), and impersonation scams (fraudster poses as a bank, government agency, or law enforcement to redirect funds). Detecting APP fraud means combining behavioral signals with transaction data. Long session pauses, copy-pasted payment entries, typing patterns consistent with phone coaching, and remote-access tools in the background all suggest a fraudster guiding a victim through a transfer. These signals, layered on first-time payee flags, unusual amounts, and out-of-pattern timing, produce reliable detection. Device intelligence and behavioral biometrics on both the sending and receiving account give firms coverage that transaction checks alone miss. Mule accounts on the receiving side are a critical vector. Fraudsters recruit holders or fabricate accounts to collect proceeds, then layer and withdraw the funds. Blocking synthetic and stolen identities at onboarding, before they can receive funds, matters as much as controls on the sending side. The UK’s Payment Systems Regulator (PSR) now requires payment service providers to reimburse APP fraud victims up to £85,000 per claim, with liability split equally between the sending and receiving firm. The split is significant: the receiving institution is now a financially responsible party, not a bystander. Whether £85,000 is high enough is contested, since many investment and impersonation scams exceed that figure. The reimbursement mandate turns APP fraud from a customer-experience problem into direct P&L exposure for PSPs on both sides of the payment. Confirmation of Payee (CoP) is live across UK payment firms as a front-line control. Before authorizing a payment, CoP checks whether the name the payer entered matches the name on the receiving account. It does not eliminate APP fraud: fraudsters can coach victims to override mismatch warnings or open mule accounts in their own name. But it reduces impersonation and misdirected-payment cases, and firms that skip it face greater liability under PSR rules.

​
How can Sardine help?

Sardine’s machine learning models pull device data and behavioral signals from the business’s platform and combine them with consortium data on the specific bank account or card. Those risk scores run through a no-code rule editor you configure to catch complex fraud patterns at whatever granularity your business requires.For card, bank, and ACH funding events, Sardine queries dozens of third-party data providers to verify account validity, ownership match, and likely settlement balance. Combined with device and behavioral signals, those checks produce an accurate reversal-risk score.For APP fraud, Sardine’s Device Intelligence and Behavioral Biometrics (DIBB) layer captures how a user interacts with the app during a payment: typing cadence, hesitation, copy-paste behavior, and remote-access tool signatures. Phone-coached sessions produce distinct behavioral patterns. Sardine scores those patterns in real time, before the payment leaves the sending firm.On the receiving side, Sardine’s identity fraud detection catches synthetic and stolen identities at onboarding, before a mule account can accept funds. Bank account validation checks ownership and risk at the moment of linking. AML transaction monitoring and network graph tooling track how proceeds move across accounts, so compliance teams can map and shut down fraud rings.For high-risk sessions, Sardine triggers step-up friction: OTP, video verification, or a cooling-off delay. This keeps approval rates intact while stopping coerced payments.Sardine’s support and data science teams work directly with clients to tune detection models to their specific fraud risk profile.

​
Next Steps

Contact us to schedule a demo and get access to our Integration Guides and API docs.