Payments Academy
Account validation PAYMENT OPERATIONS STARTED LIVE 01 Account validation - first check, and it must confirm ACTIVE 02 Sanctions screening - because a single breach can cost a bank QUEUED 03 Fraud scoring - uses behaviour rather than lists to judge QUEUED 04 Velocity and limit - protect against both fraud and simple QUEUED 05 Check flags - When a check flags a payment QUEUED 06 Hold - key design rule is that a hold is a pause QUEUED Account validation is the first check, and it must confirm that the beneficiary account exists and can receive funds. Step 1 of 6 Account validation STARTED Account validation first check, and it must confirm ACTIVE Sanctions screening because a single breach can cost a bank QUEUED Fraud scoring uses behaviour rather than lists to judge QUEUED Velocity and limit protect against both fraud and simple QUEUED Check flags When a check flags a payment QUEUED Hold key design rule is that a hold is a pause QUEUED Account validation is the first check, and it must confirm that the beneficiary account exists and can receive funds.
Sanctions screening must run on every payment PAYMENT OPERATIONS IN PROGRESS LIVE 01 Account validation - first check, and it must confirm DONE 02 Sanctions screening - because a single breach can cost a bank ACTIVE 03 Fraud scoring - uses behaviour rather than lists to judge QUEUED 04 Velocity and limit - protect against both fraud and simple QUEUED 05 Check flags - When a check flags a payment QUEUED 06 Hold - key design rule is that a hold is a pause QUEUED Sanctions screening must run on every payment, because a single breach can cost a bank millions in fines. Step 2 of 6 Sanctions screening must run on every payment IN PROGRESS Account validation first check, and it must confirm DONE Sanctions screening because a single breach can cost a bank ACTIVE Fraud scoring uses behaviour rather than lists to judge QUEUED Velocity and limit protect against both fraud and simple QUEUED Check flags When a check flags a payment QUEUED Hold key design rule is that a hold is a pause QUEUED Sanctions screening must run on every payment, because a single breach can cost a bank millions in fines.
Fraud scoring runs alongside screening PAYMENT OPERATIONS IN PROGRESS LIVE 01 Account validation - first check, and it must confirm DONE 02 Sanctions screening - because a single breach can cost a bank DONE 03 Fraud scoring - uses behaviour rather than lists to judge ACTIVE 04 Velocity and limit - protect against both fraud and simple QUEUED 05 Check flags - When a check flags a payment QUEUED 06 Hold - key design rule is that a hold is a pause QUEUED Fraud scoring runs alongside screening, and it uses behaviour rather than lists to judge risk. Step 3 of 6 Fraud scoring runs alongside screening IN PROGRESS Account validation first check, and it must confirm DONE Sanctions screening because a single breach can cost a bank DONE Fraud scoring uses behaviour rather than lists to judge ACTIVE Velocity and limit protect against both fraud and simple QUEUED Check flags When a check flags a payment QUEUED Hold key design rule is that a hold is a pause QUEUED Fraud scoring runs alongside screening, and it uses behaviour rather than lists to judge risk.
Velocity and limit checks PAYMENT OPERATIONS IN PROGRESS LIVE 01 Account validation - first check, and it must confirm DONE 02 Sanctions screening - because a single breach can cost a bank DONE 03 Fraud scoring - uses behaviour rather than lists to judge DONE 04 Velocity and limit - protect against both fraud and simple ACTIVE 05 Check flags - When a check flags a payment QUEUED 06 Hold - key design rule is that a hold is a pause QUEUED Velocity and limit checks protect against both fraud and simple mistakes. Step 4 of 6 Velocity and limit checks IN PROGRESS Account validation first check, and it must confirm DONE Sanctions screening because a single breach can cost a bank DONE Fraud scoring uses behaviour rather than lists to judge DONE Velocity and limit protect against both fraud and simple ACTIVE Check flags When a check flags a payment QUEUED Hold key design rule is that a hold is a pause QUEUED Velocity and limit checks protect against both fraud and simple mistakes.
Check flags PAYMENT OPERATIONS IN PROGRESS LIVE 01 Account validation - first check, and it must confirm DONE 02 Sanctions screening - because a single breach can cost a bank DONE 03 Fraud scoring - uses behaviour rather than lists to judge DONE 04 Velocity and limit - protect against both fraud and simple DONE 05 Check flags - When a check flags a payment ACTIVE 06 Hold - key design rule is that a hold is a pause QUEUED When a check flags a payment, the system must hold it without losing it or confusing the customer. Step 5 of 6 Check flags IN PROGRESS Account validation first check, and it must confirm DONE Sanctions screening because a single breach can cost a bank DONE Fraud scoring uses behaviour rather than lists to judge DONE Velocity and limit protect against both fraud and simple DONE Check flags When a check flags a payment ACTIVE Hold key design rule is that a hold is a pause QUEUED When a check flags a payment, the system must hold it without losing it or confusing the customer.
Hold: pause, not failure PAYMENT OPERATIONS COMPLETE LIVE 01 Account validation - first check, and it must confirm DONE 02 Sanctions screening - because a single breach can cost a bank DONE 03 Fraud scoring - uses behaviour rather than lists to judge DONE 04 Velocity and limit - protect against both fraud and simple DONE 05 Check flags - When a check flags a payment DONE 06 Hold - key design rule is that a hold is a pause ACTIVE The key design rule is that a hold is a pause, not a failure, and the payment must never be silently dropped. Step 6 of 6 Hold: pause, not failure COMPLETE Account validation first check, and it must confirm DONE Sanctions screening because a single breach can cost a bank DONE Fraud scoring uses behaviour rather than lists to judge DONE Velocity and limit protect against both fraud and simple DONE Check flags When a check flags a payment DONE Hold key design rule is that a hold is a pause ACTIVE The key design rule is that a hold is a pause, not a failure, and the payment must never be silently dropped.

Key points of this lesson, in order.

0:00 / 3:19 Step 1 of 6

Real-Time Validation, Screening and Fraud Checks in Milliseconds

Real-Time Payments Architecture, Lesson 4 of 7, Narration 3:19, D05 Domestic payment systems

Remittance informationSanctions screeningFraud scoring

What you will learn

Your objective. By the end of this lesson, you will be able to explain real-time validation, screening and fraud checks in milliseconds. Account validation is the first check, and it must confirm that the beneficiary account exists and can receive funds.

Why it matters. An analyst reviews the case in a workbench that shows the full payment details, the screening hits, and the fraud score.

Chapter objective: Learner designs real-time payments architecture, covering 24 by 7 availability, instant clearing, liquidity, and failure handling, and explains how it differs from batch systems. Learner applies this skill in realistic banking scenarios, with clear examples and correct terminology throughout.

Key learning points

  • Account validation
  • Sanctions screening must run on every payment
  • Fraud scoring runs alongside screening
  • Velocity and limit checks
  • Check flags
  • Hold: pause, not failure

Key terms

Remittance information: Information that explains what a payment is for, such as invoice numbers, contract references or salary month.

Sanctions screening: Checking payment parties, countries and references against sanctions lists published by governments and international bodies.

Fraud scoring: A risk score assigned to a payment based on factors such as amount, location, device, velocity and customer history.

Banking architecture diagram showing Real-Time Validation, Screening and Fraud Checks in Milliseconds.

Insights and practice scenarios

Worked insights and practice scenarios for this lesson. Each one is a reusable PaymentForge case, so the same case may appear in more than one lesson.

Practise this lesson

Exercise

Decide what the screening or monitoring outcome should be for the scenario in this lesson.

Use the lists, rules and thresholds in this lesson.

  1. What to do. State whether the payment is stopped, held, frozen or released, and what must be recorded for audit.

Correct result. A true match against a sanctions list stops the payment. A false positive is cleared with a reason recorded. An alert that is escalated becomes a case, and a case that meets the threshold becomes a suspicious activity report.

Why. Screening is a control, not a suggestion. A missed true match is a regulatory breach, and an unexplained clearance is an audit finding.

Check your understanding

Practice question

Which of the following best describes real-time validation, screening and fraud checks in milliseconds?

Takeaway and next step

What to remember

The key design rule is that a hold is a pause, not a failure, and the payment must never be silently dropped.

Follow GBP 850 through every stage, from instruction to beneficiary credit, and note where it can stop.

Open the Payment Lifecycle Simulator →

Builds on "Timeouts, Duplicate Prevention and Idempotency".

Transcript and full text

Show transcript

Account validation is the first check, and it must confirm that the beneficiary account exists and can receive funds. The sender bank checks the account number format, the sort code or IBAN checksum, and the scheme routing table. Confirmation of payee then compares the name the payer typed with the name on the account, returning a match, a close match, or no match. A GBP 850 payment to a correctly named account passes in under 100 milliseconds. A no-match result does not automatically block the payment, but it triggers a warning that asks the payer to confirm, which has prevented many misdirected payments since the service launched. Sanctions screening must run on every payment, because a single breach can cost a bank millions in fines. The screening engine compares the payer name, the payee name, and any remittance information against sanctions lists, such as those published by the United Nations, the European Union, and the United States Office of Foreign Assets Control. Modern engines use fuzzy matching to catch spelling variations, so a name like Mohamed and a name like Mohammed are treated as possible matches. The check must complete in under 200 milliseconds for most payments, which means the lists are held in memory and updated several times a day rather than queried from a slow external database. Fraud scoring runs alongside screening, and it uses behaviour rather than lists to judge risk. The model looks at the amount, the time of day, the device, the location, and the history between the payer and the payee. A EUR 40 payment to a supermarket the customer visits weekly scores very low. A EUR 9,500 payment at two in the morning to a brand-new payee from a new device scores very high. The score is computed in under 150 milliseconds, and a high score routes the payment to step-up authentication, such as a one-time passcode or biometric approval, while a low score lets it proceed without friction. Velocity and limit checks protect against both fraud and simple mistakes. A bank might allow a retail customer to send up to GBP 10,000 per day through Faster Payments, with a per-transaction limit of GBP 5,000. The system counts the payments already made that day and rejects or holds any payment that would exceed the limit. Velocity rules also catch bursts, such as ten payments of EUR 900 in five minutes, which can indicate an account takeover even when each payment is below the limit. These counters are stored in a fast cache with a short expiry, so the check adds only a few milliseconds to the journey. When a check flags a payment, the system must hold it without losing it or confusing the customer. A held payment sits in a pending queue with a clear reason code, such as sanctions review or fraud review, and a deadline for a decision. An analyst reviews the case in a workbench that shows the full payment details, the screening hits, and the fraud score. If the analyst clears the payment, it proceeds to the scheme immediately, even if several minutes have passed. If the analyst rejects it, the debit is reversed and the customer receives a clear message. The key design rule is that a hold is a pause, not a failure, and the payment must never be silently dropped.

Account validation is the first check, and it must confirm that the beneficiary account exists and can receive funds. The sender bank checks the account number format, the sort code or IBAN checksum, and the scheme routing table. Confirmation of payee then compares the name the payer typed with the name on the account, returning a match, a close match, or no match. A GBP 850 payment to a correctly named account passes in under 100 milliseconds. A no-match result does not automatically block the payment, but it triggers a warning that asks the payer to confirm, which has prevented many misdirected payments since the service launched.

Sanctions screening must run on every payment, because a single breach can cost a bank millions in fines. The screening engine compares the payer name, the payee name, and any remittance information against sanctions lists, such as those published by the United Nations, the European Union, and the United States Office of Foreign Assets Control. Modern engines use fuzzy matching to catch spelling variations, so a name like Mohamed and a name like Mohammed are treated as possible matches. The check must complete in under 200 milliseconds for most payments, which means the lists are held in memory and updated several times a day rather than queried from a slow external database.

Fraud scoring runs alongside screening, and it uses behaviour rather than lists to judge risk. The model looks at the amount, the time of day, the device, the location, and the history between the payer and the payee. A EUR 40 payment to a supermarket the customer visits weekly scores very low. A EUR 9,500 payment at two in the morning to a brand-new payee from a new device scores very high. The score is computed in under 150 milliseconds, and a high score routes the payment to step-up authentication, such as a one-time passcode or biometric approval, while a low score lets it proceed without friction.

Velocity and limit checks protect against both fraud and simple mistakes. A bank might allow a retail customer to send up to GBP 10,000 per day through Faster Payments, with a per-transaction limit of GBP 5,000. The system counts the payments already made that day and rejects or holds any payment that would exceed the limit. Velocity rules also catch bursts, such as ten payments of EUR 900 in five minutes, which can indicate an account takeover even when each payment is below the limit. These counters are stored in a fast cache with a short expiry, so the check adds only a few milliseconds to the journey.

When a check flags a payment, the system must hold it without losing it or confusing the customer. A held payment sits in a pending queue with a clear reason code, such as sanctions review or fraud review, and a deadline for a decision. An analyst reviews the case in a workbench that shows the full payment details, the screening hits, and the fraud score. If the analyst clears the payment, it proceeds to the scheme immediately, even if several minutes have passed. If the analyst rejects it, the debit is reversed and the customer receives a clear message. The key design rule is that a hold is a pause, not a failure, and the payment must never be silently dropped.

Full lesson text (all scenes)

Completing a lesson updates your progress dashboard on the homepage.

Scene timestamps are estimated by allocating the narration text proportionally across the real audio length. The audio playback position is the source of truth: pause freezes the visual, seeking restores the correct scene, replay restarts the scene animation.