Fraud, Sanctions and Compliance Services

Fraud and sanctions services sit in the middle of the hub pipeline, and a payment cannot proceed until they have cleared it. The fraud service scores the payment using rules and machine learning models, looking at the amount, the payee, the device, the location and the customer's history. A low score lets the payment continue automatically, a medium score may trigger step up authentication, such as a one time passcode, and a high score holds the payment for manual review. The sanctions service, covered in detail in the sanctions chapter, screens all parties and free text against the relevant lists and produces a clear, alert or hit result. Both services must respond quickly, because a payment held for seconds feels slow to a customer, and a payment held for minutes can miss a clearing window. These services are deliberately kept separate from the processing engine, so that their rules can change without touching the core flow. Fraud rules change frequently as new patterns emerge, and sanctions lists update several times a week, so the hub must support hot updates to these services. The integration pattern is usually synchronous for the first screening, because the payment cannot proceed without the result, and asynchronous for deeper investigation, where the case management system works on the alert while the payment waits. The hub must also handle the case where a service is down, with a clear policy. Either hold payments until the service returns, or route them to manual review, but never silently skip the check. That fail safe behaviour is a regulatory expectation, not a design preference. From a BA standpoint, the requirements for these services are about outcomes and evidence, not about the algorithms. What score triggers what action, who can override a hold, what evidence must be recorded, how long can a payment wait, and what message does the customer receive? The audit trail is critical, because a regulator may ask why a particular payment was released, and the bank must be able to show the fraud score, the sanctions result, the analyst's decision and the timestamp for each step. Designing these requirements well means working closely with the compliance and fraud teams, who own the rules, while the BA owns the flow that carries the payment through them. A worked example shows why the order of controls matters. A corporate payment of EUR 500,000 from a customer in Frankfurt to a supplier in Singapore arrives at the hub at 10:00. Fraud screening runs first and scores the payment as low risk because the beneficiary is an established supplier and the amount matches the customer's normal pattern. Sanctions screening runs next and flags the payment because the supplier name is similar to a name on the EU sanctions list. The payment stops. The sanctions team reviews the match, finds it is a false positive because the supplier is a different company in a different country, and releases the payment with a record of the decision. The payment then goes to routing and settles through the correspondent the same day. If sanctions screening had run after routing, the payment would have been sent before the flag was raised, and the bank would have had to recall it. The order of controls is a design decision, and a business analyst must specify it explicitly. A failure scenario tests the controls. A payment of USD 2 million is instructed by a corporate customer whose account has been taken over by a fraudster. The fraud screen scores it as high risk because the amount is ten times the customer's normal payment and the beneficiary is a new account opened three days ago. The payment stops in the fraud worklist. The fraud team calls the customer, who confirms they did not instruct the payment, and the payment is rejected. The account is frozen and the customer is asked to change their credentials. If the fraud screen had not run, or if it had scored the payment as low risk, the USD 2 million would have left the bank and the recovery would have depended on the beneficiary bank's cooperation. For a business analyst, the requirement is to define the fraud rules, the risk score thresholds, the action for each score band, and the evidence the fraud team needs to decide. Last reviewed 7 November 2026. Further reading: bank payment fraud and sanctions screening procedures; SWIFT Customer Security Programme. Take a payment of GBP 45,000 from a small business to a new supplier in a high risk country. The fraud service scores it at 82 out of 100, because the payee is new, the amount is ten times the customer's usual payment, and the device has never been seen before. The score triggers step up authentication, and the customer confirms the payment with a one time passcode. The sanctions service then screens the payee name and finds a possible match against a list entry, so the payment waits in the analyst queue for 40 minutes while the analyst checks the date of birth and the address and clears it as a false positive. The payment then releases, but it has missed the Faster Payments window the customer expected. Two services can each add delay, and the total delay is what the customer feels. When the fraud service is down, the hub faces a hard choice. It can hold all payments until the service returns, which protects the bank but stops every customer payment, or it can route payments to manual review, which keeps some payments moving but needs enough analysts to work the queue. Most banks choose to hold, because releasing a payment without a fraud score or a sanctions check is a regulatory breach, not a service decision. The hub must therefore record exactly which payments were held, for how long, and why, and it must replay them in the right order when the service returns. A BA should write the failover requirement as a decision table: which service is down, what the hub does, who is told, and how the backlog is cleared. The requirements that matter most here are the ones that define evidence. For every payment that passes through these services, the hub must store the fraud score, the model version, the sanctions result, the list versions screened against, the analyst decision, and the timestamp of each step. That evidence is what the bank shows a regulator after an incident, and it is what operations uses to explain a delay to a customer. The BA should also define the service level for each service, such as a fraud score in under 200 milliseconds and a sanctions result in under 500 milliseconds, because a slow service is a queue, and a queue is a missed value date.