Payments Training Hub
Validation: set of checks 1 Validation NOW 2 Validation failure rejection 3 Good enrichment 4 At each state 5 Take a payment from a corporate Validation is the set of checks that confirm a payment is complete, correct and allowed before any money moves. Step 1 of 5 Validation: set of checks 1 NOW Validation 2 Validation failure rejection 3 Good enrichment 4 At each state 5 Take a payment from a corporate Validation is the set of checks that confirm a payment is complete, correct and allowed before any money moves. Step 1 of 5
Validation failure rejection 1 Validation 2 Validation failure rejection NOW 3 Good enrichment 4 At each state 5 Take a payment from a corporate A payment that fails validation is rejected back to the channel with a clear reason code, so the customer or the corporate system can fix it and resend. Step 2 of 5 Validation failure rejection 1 Validation 2 NOW Validation failure rejection 3 Good enrichment 4 At each state 5 Take a payment from a corporate A payment that fails validation is rejected back to the channel with a clear reason code, so the customer or the corporate system can fix it and resend. Step 2 of 5
Good enrichment 1 Validation 2 Validation failure rejection 3 Good enrichment NOW 4 At each state 5 Take a payment from a corporate Good enrichment design keeps the channel simple, because the channel only needs to capture the essentials, while the hub supplies the rest from trusted reference data. Step 3 of 5 Good enrichment 1 Validation 2 Validation failure rejection 3 NOW Good enrichment 4 At each state 5 Take a payment from a corporate Good enrichment design keeps the channel simple, because the channel only needs to capture the essentials, while the hub supplies the rest from trusted reference data. Step 3 of 5
At each state 1 Validation 2 Validation failure rejection 3 Good enrichment 4 At each state NOW 5 Take a payment from a corporate At each state, the engine decides what happens next, calls the right service, handles errors, and updates the payment status. Step 4 of 5 At each state 1 Validation 2 Validation failure rejection 3 Good enrichment 4 NOW At each state 5 Take a payment from a corporate At each state, the engine decides what happens next, calls the right service, handles errors, and updates the payment status. Step 4 of 5
Take a payment from a corporate customer 1 Validation 2 Validation failure rejection 3 Good enrichment 4 At each state 5 Take a payment from a corporate NOW For example, take a payment from a corporate customer who sends EUR 50,000 to a supplier but leaves the beneficiary bank identifier blank. Step 5 of 5 Take a payment from a corporate customer 1 Validation 2 Validation failure rejection 3 Good enrichment 4 At each state 5 NOW Take a payment from a corporate For example, take a payment from a corporate customer who sends EUR 50,000 to a supplier but leaves the beneficiary bank identifier blank. Step 5 of 5

Steps of this lesson, in order.

0:00 / 2:55 Step 1 of 5

Validation, Enrichment and the Processing Engine

Payment Hub Architecture, Lesson 3 of 8, Narration 2:55, D09 Payment architecture and technology

Value dateSettlementClearing

What you will learn

Your objective. By the end of this lesson, you will be able to explain validation, enrichment and the processing engine. Validation is the set of checks that confirm a payment is complete, correct and allowed before any money moves.

Why it matters. For example, take a payment from a corporate customer who sends EUR 50,000 to a supplier but leaves the beneficiary bank identifier blank.

Chapter objective: Learner designs a payment hub architecture, explaining intake, validation, routing, transformation, screening, and settlement modules, and maps a payment through each module. Learner applies this skill in realistic banking scenarios, with clear examples and correct terminology throughout.

Key learning points

  • Validation: set of checks
  • Validation failure rejection
  • Good enrichment
  • At each state
  • Take a payment from a corporate customer

Key terms

Value date: The date on which funds become available to the beneficiary and on which interest starts to accrue. It is the date used for settlement and for nostro posting.

Settlement: The final movement of funds between banks to discharge obligations created by cleared payments. Settlement is usually made in central bank money or through correspondent accounts.

Clearing: The process of exchanging payment instructions between banks and calculating what each bank owes the others.

Banking architecture diagram showing Validation, Enrichment and the Processing Engine.

Practise this lesson

Exercise

Work out what the beneficiary receives for a EUR 50,000 payment under OUR, SHA and BEN.

Use the charge arrangement rules in this lesson and the correspondent and beneficiary bank fees named in the lesson.

  1. What to do. Calculate the amount credited under each of the three arrangements and state who pays each fee.

Correct result. Under OUR the sender pays all charges and the beneficiary receives the full amount. Under SHA the sender pays the sending charges and the beneficiary pays the receiving charges. Under BEN the beneficiary pays all charges and receives the amount less all fees.

Why. The charge arrangement decides who pays and how much arrives. A customer who was promised the full amount and receives less will complain, and the complaint lands on the analyst.

Check your understanding

Practice question

A payment arrives at the hub with no value date. The hub must decide when the payment is due to settle. What should it do?

Takeaway and next step

What to remember

The processing engine then moves the payment through its states, from received to validated to enriched to screened, and releases it for settlement, with every step recorded in the status the customer can see.

Send a payment through the hub and watch it pass each component named in this lesson.

Open the Payment Hub Architecture Simulator →

Builds on "Channels and the Gateway".

Transcript and full text

Show transcript

Validation is the set of checks that confirm a payment is complete, correct and allowed before any money moves. Business validation checks that the mandatory fields are present, that the currency is supported, that the value date is valid, and that the payment amount is within the customer's limits. Account validation checks that the debit account exists, belongs to the customer, is in the right status, and has sufficient funds or an approved overdraft. Reference data validation checks that the beneficiary bank identifier is real, that the country and currency combination is supported, and that the payment type is allowed for that channel. A payment that fails validation is rejected back to the channel with a clear reason code, so the customer or the corporate system can fix it and resend. Enrichment is the step where the hub adds information the payment needs but the channel did not supply. This might include the full name and address of the beneficiary bank, looked up from a directory, the charges that will apply, the exchange rate for a currency conversion, or the routing details for the chosen clearing scheme. Enrichment is also where the hub applies customer specific settings, such as a preferred charging option or a default value date. Good enrichment design keeps the channel simple, because the channel only needs to capture the essentials, while the hub supplies the rest from trusted reference data. The risk is that stale reference data produces wrong enrichment, so the hub's reference data must be updated reliably and on time. The processing engine, sometimes called the orchestrator, is the heart of the hub. It moves the payment through its lifecycle as a state machine. Received, validated, enriched, screened, authorised, routed, released, settled and confirmed. At each state, the engine decides what happens next, calls the right service, handles errors, and updates the payment status. If a service is unavailable, the engine can retry, park the payment, or route it to manual repair, depending on the configuration. The engine also enforces cut off times, so a payment received after the clearing cut off is held for the next window. A BA should be able to draw the state machine for a payment type, because that diagram is the shared language between business, operations and technology. For example, take a payment from a corporate customer who sends EUR 50,000 to a supplier but leaves the beneficiary bank identifier blank. Validation catches the missing field and rejects the payment back to the channel with a clear reason code, so the customer can correct it and resend. On the second attempt the payment passes validation, and enrichment adds the beneficiary bank name and address from the bank directory, plus the charge of EUR 25 that applies to this payment type. The processing engine then moves the payment through its states, from received to validated to enriched to screened, and releases it for settlement, with every step recorded in the status the customer can see.

Validation is the set of checks that confirm a payment is complete, correct and allowed before any money moves. Business validation checks that the mandatory fields are present, that the currency is supported, that the value date is valid, and that the payment amount is within the customer's limits. Account validation checks that the debit account exists, belongs to the customer, is in the right status, and has sufficient funds or an approved overdraft. Reference data validation checks that the beneficiary bank identifier is real, that the country and currency combination is supported, and that the payment type is allowed for that channel. A payment that fails validation is rejected back to the channel with a clear reason code, so the customer or the corporate system can fix it and resend.

Enrichment is the step where the hub adds information the payment needs but the channel did not supply. This might include the full name and address of the beneficiary bank, looked up from a directory, the charges that will apply, the exchange rate for a currency conversion, or the routing details for the chosen clearing scheme. Enrichment is also where the hub applies customer specific settings, such as a preferred charging option or a default value date. Good enrichment design keeps the channel simple, because the channel only needs to capture the essentials, while the hub supplies the rest from trusted reference data. The risk is that stale reference data produces wrong enrichment, so the hub's reference data must be updated reliably and on time.

The processing engine, sometimes called the orchestrator, is the heart of the hub. It moves the payment through its lifecycle as a state machine. Received, validated, enriched, screened, authorised, routed, released, settled and confirmed. At each state, the engine decides what happens next, calls the right service, handles errors, and updates the payment status. If a service is unavailable, the engine can retry, park the payment, or route it to manual repair, depending on the configuration. The engine also enforces cut off times, so a payment received after the clearing cut off is held for the next window. A BA should be able to draw the state machine for a payment type, because that diagram is the shared language between business, operations and technology.

For example, take a payment from a corporate customer who sends EUR 50,000 to a supplier but leaves the beneficiary bank identifier blank. Validation catches the missing field and rejects the payment back to the channel with a clear reason code, so the customer can correct it and resend. On the second attempt the payment passes validation, and enrichment adds the beneficiary bank name and address from the bank directory, plus the charge of EUR 25 that applies to this payment type. The processing engine then moves the payment through its states, from received to validated to enriched to screened, and releases it for settlement, with every step recorded in the status the customer can see.

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.