The Bank Transactions system evaluates every account transfer in real time, whether it is inbound or outbound. For each transfer, the system takes into account the behavior, the receiver, and any bank that is involved. Authorized push payment scams and mule activity are detected while the transfer is still being carried out, and your fraud team is immediately informed so that they can choose to hold, block, or release the payment before it is executed.
With instant payment systems, a transfer completes in just a few seconds. To prevent fraud, you must examine the transfer, check everyone involved, score the risk, and decide, all before the funds leave the account. Speed alone is not enough. What looks like fraud to one customer may be a regular payment to another, so the risk assessment must be based on your own rules and your own level of risk appetite. Without both, transactions will move faster than your controls.
A fraud score is assigned to each transfer as soon as it arrives, regardless of whether the transfer is a sent or received one. The score is available before the payment is carried out, not only after the customer has contacted to report it.
On each transfer, the payer, the payee, and any intermediary bank are checked. The score considers the amount and timing, as well as the sender's behavior, session, and account history, not just the transaction itself.
Fraud is detected in real time, so the transfer can be halted before the money leaves the account; but if it has already gone, recovery is slow and usually incomplete.
The transfer, the payee and the context arrive for scoring before it completes.
The beneficiary account is checked for mule links, reuse and known-fraud signals.
Sender behaviour and payee risk combine into a scam score in real time.
A high score warns the sender, holds the transfer, or lets a clean payment through.
| Rule | Detail | Score | |
|---|---|---|---|
| unusual hour | mule-linked payee | High |
Each account-to-account transfer, whether sent or received, is assessed before it is carried out, and the decision is returned in the payment process in time to enable instant payment rails.
The system flags manipulative patterns in the sender's behavior, such as urgency, a first payment to a new account, or an unusual amount, as they happen. The platform detects the pattern and alerts the responsible team.
The beneficiary accounts are examined for mule links, for reuse across different senders, and for any known fraud indicators, and a payee who receives money from six unrelated senders over a period of two days is flagged before the next transfer takes place.
As soon as a high-risk transfer is assessed, an alert will be sent to both your fraud and operations teams together with the relevant signals. Where your policy permits, the sender can also be warned during the payment process.
Build flows that stop a transfer if the risk requires it; hold a high-risk payment for a specified period, ask the sender to confirm it, or block it completely. Clean payments go through without delay.
Each score, alert, hold, and release is accompanied by a record of the rule which caused it and the user who took action. Any decision can then be explained to an auditor, a regulator or the customer.
Transfers going in and out are assessed using a live fraud score, with the highest-risk ones appearing first, along with the signals that drive them.
The rules that trigger the action, the sender's behavior, and the risk level associated with the score are set and adjusted by your team.
The mule links and reuse across accounts were scored by both payers and payees for each transfer they were involved in.
Before a transfer is carried out, every score considers the transfer, the payer's behavior, the payee's risk, and the account history.
The Fusion score should include risk associated with a customer who is repeatedly targeted or an account exhibiting mule behavior. The same system that assesses the customer's AML risk also processes transfer signals, so both fraud and AML concerns are recorded on the same record.
Send each transfer via the API so the platform can apply your rules, then you will receive a score, the reason, and the action before the payment is carried out. Also, payees can be checked by the users themselves prior to the first transfer.
Yes. Every transfer is scored as soon as it arrives, whether it is sent or received. Inbound scoring is what catches mule accounts. An account that suddenly receives funds from several unrelated senders and quickly moves them on is flagged before the money moves further down the chain.
By combining the sender’s behavior with the payee’s risk. The payment details can look legitimate. But a first payment to a new beneficiary, at an unusual hour, from a high-risk session, to a payee other senders have also paid, raises the scam score before the transfer completes.
The beneficiary is checked for mule links, reuse across unrelated senders, and known-fraud signals. A payee that several of your customers paid for the first time within a short window is treated very differently from a long-standing account that is paid regularly.
Yes. Each score maps to an action you define: warn the sender, hold the transfer for review, block it, or release it. A hold gives your fraud team time to reach the customer, so a genuine payment is delayed rather than lost.
Because the risk isn't limited to the two accounts. An unexpected or high-risk routing bank can signal risk on its own. So we check every bank in the payment chain alongside the payer and the payee.
Not if they are regular for that customer. Scoring runs on your own rules and risk appetite, and on each customer’s own history. A large monthly transfer to a known supplier is normal for one customer and unusual for another, and the score reflects that difference.
In real time, within the window of an instant payment. The score, the rules that fired, and the recommended action come back before the transfer is executed. Your team decides while the money is still in the account.
An alert with the transfer, the payee profile, the rules that fired, and how much each one added to the score. The team can hold, block or release from the same screen. The case keeps a full record of what was decided and why.
All three run on Fusion and share the same customer record. Device and session signals feed into the transfer score, and a confirmed fraud case updates the customer’s risk. Fraud and AML teams work from one view instead of separate systems.
Through a single scoring call that sits before the transfer is executed. Transfer, payee and session data go in. The score, the rules that fired and the recommended action come back. Your core banking system or payment gateway then holds, blocks or releases the transfer based on that response.
complead provides ultimate control via its case management and safelist systems. Automated API operations significantly reduced my team's manual workload.
Using the API we run AML controls automatically and stay compliant, while reducing our team's daily workload.
With complead we offer fast, easy, secure onboarding. We focus on real risks, not false positives.
Bring a sample of account transfers. In a 30-minute session, we score them for fraud risk, check every payee, and show which transfers your team would have stopped.