Payments Academy
Payment lifecycle 1 Payment lifecycle NOW 2 Core 3 Separation 4 Discipline 5 Database connections 6 Scheduler A payment lifecycle is implemented as a finite state machine Step 1 of 6 Payment lifecycle 1 NOW Payment lifecycle 2 Core 3 Separation 4 Discipline 5 Database connections 6 Scheduler A payment lifecycle is implemented as a finite state machine Step 1 of 6
Core: payment instruction table 1 Payment lifecycle 2 Core NOW 3 Separation 4 Discipline 5 Database connections 6 Scheduler The core of the design is a payment instruction table that holds one row per payment Step 2 of 6 Core: payment instruction table 1 Payment lifecycle 2 NOW Core 3 Separation 4 Discipline 5 Database connections 6 Scheduler The core of the design is a payment instruction table that holds one row per payment Step 2 of 6
Separation keeps the main table 1 Payment lifecycle 2 Core 3 Separation NOW 4 Discipline 5 Database connections 6 Scheduler This separation keeps the main table fast for lookups while preserving a complete record of the payment journey. Step 3 of 6 Separation keeps the main table 1 Payment lifecycle 2 Core 3 NOW Separation 4 Discipline 5 Database connections 6 Scheduler This separation keeps the main table fast for lookups while preserving a complete record of the payment journey. Step 3 of 6
Discipline turns the lifecycle 1 Payment lifecycle 2 Core 3 Separation 4 Discipline NOW 5 Database connections 6 Scheduler This discipline turns the lifecycle from a black box into a transparent and defensible process. Step 4 of 6 Discipline turns the lifecycle 1 Payment lifecycle 2 Core 3 Separation 4 NOW Discipline 5 Database connections 6 Scheduler This discipline turns the lifecycle from a black box into a transparent and defensible process. Step 4 of 6
Database connections 1 Payment lifecycle 2 Core 3 Separation 4 Discipline 5 Database connections NOW 6 Scheduler Database connections are pooled, hot tables are partitioned by business date, and read replicas serve status queries so the main write path stays fast under load. Step 5 of 6 Database connections 1 Payment lifecycle 2 Core 3 Separation 4 Discipline 5 NOW Database connections 6 Scheduler Database connections are pooled, hot tables are partitioned by business date, and read replicas serve status queries so the main write path stays fast under load. Step 5 of 6
Scheduler checks cut offs 1 Payment lifecycle 2 Core 3 Separation 4 Discipline 5 Database connections 6 Scheduler NOW A scheduler checks cut offs every minute, releases queued payments in priority order, and raises alerts when the queue depth passes a threshold such as 50,000 pending items. Step 6 of 6 Scheduler checks cut offs 1 Payment lifecycle 2 Core 3 Separation 4 Discipline 5 Database connections 6 NOW Scheduler A scheduler checks cut offs every minute, releases queued payments in priority order, and raises alerts when the queue depth passes a threshold such as 50,000 pending items. Step 6 of 6

Steps of this lesson, in order.

0:00 / 3:25 Step 1 of 6

System design deep dive: how the lifecycle is built inside a bank

Payment Lifecycle End to End, Lesson 8 of 9, Narration 3:25, D03 Payment lifecycle

SettlementValue dateClearing

What you will learn

Your objective. By the end of this lesson, you will be able to explain system design deep dive: how the lifecycle is built inside a bank. A payment lifecycle is implemented as a finite state machine, and every state has a clear owner, a set of allowed transitions, and a set of actions that must complete before the payment can move on.

Why it matters. Operations teams use this trail to answer customer queries, investigate delays, and prove compliance during audits.

Chapter objective: Learner walks a payment from initiation through validation, screening, clearing, settlement, and reconciliation, and identifies the controls and failure points at each stage of the lifecycle. Learner applies this skill in realistic banking scenarios, with clear examples and correct terminology throughout.

Key learning points

  • Payment lifecycle
  • Core: payment instruction table
  • Separation keeps the main table
  • Discipline turns the lifecycle
  • Database connections
  • Scheduler checks cut offs

Key terms

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.

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.

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

Animated payment lifecycle showing System design deep dive: how the lifecycle is built inside a bank.

Practise this lesson

Exercise

Trace the payment in this lesson through its lifecycle stages.

Use the lifecycle stages in this lesson: acceptance, processing, clearing, settlement, beneficiary credit, ledger posting and reconciliation.

  1. What to do. Name each stage, state what happens, and say when the payment is truly final.

Correct result. Acceptance validates the instruction. Processing prepares it. Clearing sorts and nets it. Settlement moves the funds. Beneficiary credit puts the money in the creditor account. Ledger posting records it. Reconciliation proves it. Finality is only at settlement, not at acceptance or at status update.

Why. The lifecycle is the map of a payment. If you cannot say which stage a payment is in, you cannot answer where the money is.

Check your understanding

Practice question

Which of the following best describes system design deep dive: how the lifecycle is built inside a bank?

Takeaway and next step

What to remember

The engine never allows a jump from received straight to settled, because each transition is enforced by code and by database constraints.

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

Open the Payment Lifecycle Simulator →

Builds on "Exceptions, returns, recalls and investigations".

Transcript and full text

Show transcript

A payment lifecycle is implemented as a finite state machine, and every state has a clear owner, a set of allowed transitions, and a set of actions that must complete before the payment can move on. Typical states include received, validated, enriched, sanction screened, queued, released, sent, acknowledged, settled, and completed, with separate branches for rejected, returned, and repaired payments. The engine never allows a jump from received straight to settled, because each transition is enforced by code and by database constraints. This design makes the flow predictable, testable, and safe to operate at high volume, because an invalid transition is rejected before it can corrupt downstream processing. The core of the design is a payment instruction table that holds one row per payment, with a status column, a version number, timestamps for every major milestone, and references to the customer, account, currency, amount, and beneficiary. Around it sit supporting tables for state history, charges, FX rates, screening results, and settlement instructions. The history table is append only, so each transition inserts a new row rather than overwriting the old one, and the version number supports optimistic locking so two processes cannot update the same payment at the same time. This separation keeps the main table fast for lookups while preserving a complete record of the payment journey. Every status change is audited with the user or system that made it, the time in UTC, the previous and new status, and the reason code that explains the change. Audit records are written in the same database transaction as the status update, so a payment can never change state without leaving evidence. Operations teams use this trail to answer customer queries, investigate delays, and prove compliance during audits. When a payment is repaired, the audit shows who changed the beneficiary details, what the old value was, and whether a four eyes approval was completed. This discipline turns the lifecycle from a black box into a transparent and defensible process. A large bank processes between two and five million payments every day, with peaks of 8,000 to 12,000 transactions per second during morning business hours. Month end, salary days, and tax deadlines can raise daily volume by 40 to 60 percent, so the platform is sized for peak plus a safety margin of at least 30 percent. Processing is split across worker pools, with separate queues for urgent, standard, and bulk payments, so a flood of low priority bulk files cannot block a high value urgent payment. Database connections are pooled, hot tables are partitioned by business date, and read replicas serve status queries so the main write path stays fast under load. Cut off management is built into the lifecycle as a set of rules per currency, payment type, and destination. Each payment is stamped with its value date and the cut off time of the clearing system or correspondent that will carry it. If a payment arrives after cut off, the engine either holds it for the next value date or routes it to a faster rail, and the customer is told the new expected date immediately. A scheduler checks cut offs every minute, releases queued payments in priority order, and raises alerts when the queue depth passes a threshold such as 50,000 pending items. This combination of rules, scheduling, and monitoring keeps late payments rare and visible.

A payment lifecycle is implemented as a finite state machine, and every state has a clear owner, a set of allowed transitions, and a set of actions that must complete before the payment can move on. Typical states include received, validated, enriched, sanction screened, queued, released, sent, acknowledged, settled, and completed, with separate branches for rejected, returned, and repaired payments. The engine never allows a jump from received straight to settled, because each transition is enforced by code and by database constraints. This design makes the flow predictable, testable, and safe to operate at high volume, because an invalid transition is rejected before it can corrupt downstream processing.

The core of the design is a payment instruction table that holds one row per payment, with a status column, a version number, timestamps for every major milestone, and references to the customer, account, currency, amount, and beneficiary. Around it sit supporting tables for state history, charges, FX rates, screening results, and settlement instructions. The history table is append only, so each transition inserts a new row rather than overwriting the old one, and the version number supports optimistic locking so two processes cannot update the same payment at the same time. This separation keeps the main table fast for lookups while preserving a complete record of the payment journey.

Every status change is audited with the user or system that made it, the time in UTC, the previous and new status, and the reason code that explains the change. Audit records are written in the same database transaction as the status update, so a payment can never change state without leaving evidence. Operations teams use this trail to answer customer queries, investigate delays, and prove compliance during audits. When a payment is repaired, the audit shows who changed the beneficiary details, what the old value was, and whether a four eyes approval was completed. This discipline turns the lifecycle from a black box into a transparent and defensible process.

A large bank processes between two and five million payments every day, with peaks of 8,000 to 12,000 transactions per second during morning business hours. Month end, salary days, and tax deadlines can raise daily volume by 40 to 60 percent, so the platform is sized for peak plus a safety margin of at least 30 percent. Processing is split across worker pools, with separate queues for urgent, standard, and bulk payments, so a flood of low priority bulk files cannot block a high value urgent payment. Database connections are pooled, hot tables are partitioned by business date, and read replicas serve status queries so the main write path stays fast under load.

Cut off management is built into the lifecycle as a set of rules per currency, payment type, and destination. Each payment is stamped with its value date and the cut off time of the clearing system or correspondent that will carry it. If a payment arrives after cut off, the engine either holds it for the next value date or routes it to a faster rail, and the customer is told the new expected date immediately. A scheduler checks cut offs every minute, releases queued payments in priority order, and raises alerts when the queue depth passes a threshold such as 50,000 pending items. This combination of rules, scheduling, and monitoring keeps late payments rare and visible.

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.