Payments Training Hub
Unit testing PAYMENT OPERATIONS STARTED LIVE 01 Unit testing - checks the smallest piece of code in isolation ACTIVE 02 System Integration Testing - known as SIT, checks that the pieces work QUEUED 03 User Acceptance Testing - known as UAT, is owned by the business QUEUED 04 Regression testing - protects everything that already works when QUEUED 05 Four levels - These four levels work as a chain QUEUED Unit testing checks the smallest piece of code in isolation, and in payments that precision matters. Step 1 of 5 Unit testing STARTED Unit testing checks the smallest piece of code in isolation ACTIVE System Integration Testing known as SIT, checks that the pieces work QUEUED User Acceptance Testing known as UAT, is owned by the business QUEUED Regression testing protects everything that already works when QUEUED Four levels These four levels work as a chain QUEUED Unit testing checks the smallest piece of code in isolation, and in payments that precision matters.
System Integration Testing PAYMENT OPERATIONS IN PROGRESS LIVE 01 Unit testing - checks the smallest piece of code in isolation DONE 02 System Integration Testing - known as SIT, checks that the pieces work ACTIVE 03 User Acceptance Testing - known as UAT, is owned by the business QUEUED 04 Regression testing - protects everything that already works when QUEUED 05 Four levels - These four levels work as a chain QUEUED System Integration Testing, known as SIT, checks that the pieces work together as a system. Step 2 of 5 System Integration Testing IN PROGRESS Unit testing checks the smallest piece of code in isolation DONE System Integration Testing known as SIT, checks that the pieces work ACTIVE User Acceptance Testing known as UAT, is owned by the business QUEUED Regression testing protects everything that already works when QUEUED Four levels These four levels work as a chain QUEUED System Integration Testing, known as SIT, checks that the pieces work together as a system.
User Acceptance Testing PAYMENT OPERATIONS IN PROGRESS LIVE 01 Unit testing - checks the smallest piece of code in isolation DONE 02 System Integration Testing - known as SIT, checks that the pieces work DONE 03 User Acceptance Testing - known as UAT, is owned by the business ACTIVE 04 Regression testing - protects everything that already works when QUEUED 05 Four levels - These four levels work as a chain QUEUED User Acceptance Testing, known as UAT, is owned by the business and proves that the system meets real business needs. Step 3 of 5 User Acceptance Testing IN PROGRESS Unit testing checks the smallest piece of code in isolation DONE System Integration Testing known as SIT, checks that the pieces work DONE User Acceptance Testing known as UAT, is owned by the business ACTIVE Regression testing protects everything that already works when QUEUED Four levels These four levels work as a chain QUEUED User Acceptance Testing, known as UAT, is owned by the business and proves that the system meets real business needs.
Regression testing PAYMENT OPERATIONS IN PROGRESS LIVE 01 Unit testing - checks the smallest piece of code in isolation DONE 02 System Integration Testing - known as SIT, checks that the pieces work DONE 03 User Acceptance Testing - known as UAT, is owned by the business DONE 04 Regression testing - protects everything that already works when ACTIVE 05 Four levels - These four levels work as a chain QUEUED Regression testing protects everything that already works when a change is introduced. Step 4 of 5 Regression testing IN PROGRESS Unit testing checks the smallest piece of code in isolation DONE System Integration Testing known as SIT, checks that the pieces work DONE User Acceptance Testing known as UAT, is owned by the business DONE Regression testing protects everything that already works when ACTIVE Four levels These four levels work as a chain QUEUED Regression testing protects everything that already works when a change is introduced.
Four levels work as a chain PAYMENT OPERATIONS COMPLETE LIVE 01 Unit testing - checks the smallest piece of code in isolation DONE 02 System Integration Testing - known as SIT, checks that the pieces work DONE 03 User Acceptance Testing - known as UAT, is owned by the business DONE 04 Regression testing - protects everything that already works when DONE 05 Four levels - These four levels work as a chain ACTIVE These four levels work as a chain, and skipping one level creates risk. Step 5 of 5 Four levels work as a chain COMPLETE Unit testing checks the smallest piece of code in isolation DONE System Integration Testing known as SIT, checks that the pieces work DONE User Acceptance Testing known as UAT, is owned by the business DONE Regression testing protects everything that already works when DONE Four levels These four levels work as a chain ACTIVE These four levels work as a chain, and skipping one level creates risk.

Key points of this lesson, in order.

0:00 / 3:22 Step 1 of 5

Test Levels: Unit, SIT, UAT and Regression

Payment Testing and Certification, Lesson 2 of 7, Narration 3:22, D11 Operations, exceptions and reconciliation

Sanctions screeningPayment hubISO 20022

What you will learn

Your objective. By the end of this lesson, you will be able to explain test levels: unit, SIT, UAT and regression. Unit testing checks the smallest piece of code in isolation, and in payments that precision matters.

Why it matters. This matters because operations is where payments are reconciled, investigated and fixed. The work in this lesson is what keeps the money right.

Chapter objective: Learner plans payment testing and certification, including test cases, test data, simulators, and scheme certification, and writes a test plan for a new payment feature. Learner practises this skill on realistic banking cases, explaining the reasoning clearly and using correct terminology throughout the work.

Key learning points

  • Unit testing
  • System Integration Testing
  • User Acceptance Testing
  • Regression testing
  • Four levels work as a chain

Key terms

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

Payment hub: A central system in a bank that receives payment instructions from all channels, validates them, applies screening and routing rules, and sends them to the correct clearing system or correspondent.

ISO 20022: An international standard for financial messaging that defines XML message formats for payments, securities and trade.

Clearing and settlement timeline showing Test Levels: Unit, SIT, UAT and Regression.

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

Read the pacs.008 message described in this lesson and identify its key parts.

Use the message structure, fields and example in this lesson.

  1. What to do. List the three levels of the message and name the field that carries the amount and the field that carries the end-to-end reference.

Correct result. The amount is carried in the instructed amount element and the reference in the end-to-end identification. The three levels are the group header, the payment information, and the credit transfer transaction information.

Why. A message is only useful if you can read it. The group header identifies the message, the payment information identifies the batch, and the transaction information carries the single payment.

Check your understanding

Practice question

A bank is about to migrate its payment system to ISO 20022. The test manager is asked what to test first. What is the right priority?

Takeaway and next step

What to remember

The discipline is to run each level with clear entry criteria, clear exit criteria and evidence that can be shown to auditors, scheme managers and senior management before go live.

Reconcile the payment in this lesson against its statement and find the break.

Open the Accounting and Reconciliation Lab →

Builds on "Why Payment Testing Is Different".

Transcript and full text

Show transcript

Unit testing checks the smallest piece of code in isolation, and in payments that precision matters. A developer who changes the logic that calculates charges on a 10,000 euro SEPA payment writes a unit test to prove that a 12 euro charge leaves a 9,988 euro credit, not 9,987 or 9,989. The test runs in milliseconds and gives fast feedback. If the logic is wrong, the developer fixes it before the code reaches any shared environment. Strong unit tests therefore stop rounding errors, currency conversion mistakes and field mapping errors at the cheapest possible point. System Integration Testing, known as SIT, checks that the pieces work together as a system. A pacs.008 created in the payment hub must pass through sanctions screening, reach the SWIFT gateway, receive a pacs.002 status report, and update the customer account and the general ledger. SIT proves that interfaces, message formats, queues and databases work together. A typical SIT case sends a 45,000 dollar payment from HSBC to Citibank, checks the MT103 equivalent fields, and confirms that the ledger posts a debit of 45,000 dollars and a matching credit to the nostro account. User Acceptance Testing, known as UAT, is owned by the business and proves that the system meets real business needs. Business users run end to end scenarios that mirror production, such as a corporate treasurer at a UK retailer paying 850,000 pounds in salaries through a pain.001 file. They check the payment file, the approval workflow, the cut off warning and the camt.053 statement the next morning. UAT is not a repeat of SIT. It asks whether a real user can complete real work safely, and whether the result matches the business requirement that was originally approved. Regression testing protects everything that already works when a change is introduced. A bank that changes its ISO 20022 mapping for pacs.008 must still prove that existing MT103 payments, SEPA payments and domestic Faster Payments continue to work. A regression pack therefore reruns a wide set of proven scenarios, including high value payments, low value payments, returns, recalls and rejected payments. If a change breaks a previously working flow, regression testing finds it before customers do, and that protection is essential in a system that processes millions of payments every day. These four levels work as a chain, and skipping one level creates risk. A team that skips unit testing pushes simple defects into SIT, where they are slower and more expensive to fix. A team that skips UAT releases a system that is technically correct but unusable for operations staff. A team that skips regression testing risks breaking a live payment flow that customers depend on. The discipline is to run each level with clear entry criteria, clear exit criteria and evidence that can be shown to auditors, scheme managers and senior management before go live. A worked SIT case shows the chain in action. A corporate user submits a pain.001 file with 200 salary payments worth 1.2 million pounds. SIT must prove that the hub validates the file, that each payment passes sanctions screening, that the pacs.008 messages are created correctly, that the ledger posts 200 debits and one bulk credit, and that a pacs.002 status report arrives for each payment. If the screening service is down, SIT must prove that the payments queue safely and resume when the service returns. Each of these checks needs its own test case, its own expected result, and its own evidence. The cost of finding a defect rises sharply at each level, which is why the chain matters. A rounding error caught by a unit test costs minutes to fix. The same error caught in SIT costs hours, because the tester must reproduce it through the full chain and the developer must redeploy. Caught in UAT, it costs days, because business users must retest and sign off again. Caught in production, it costs money, reputation, and regulatory reporting. A business analyst who understands this cost curve will invest in clear requirements and early test design, because every defect found early is a defect that never reaches a customer. Writing the test documentation is a separate skill from running the test levels, and it is taught in ch84 BA practice depth. That chapter covers Gherkin scenarios in Given When Then form, the requirements traceability matrix, and how to design a SIT pack and a UAT pack with entry criteria, exit criteria and evidence. This chapter stays with test execution: the levels themselves, what each level proves, and the cost of finding a defect at each level.

Unit testing checks the smallest piece of code in isolation, and in payments that precision matters. A developer who changes the logic that calculates charges on a 10,000 euro SEPA payment writes a unit test to prove that a 12 euro charge leaves a 9,988 euro credit, not 9,987 or 9,989. The test runs in milliseconds and gives fast feedback. If the logic is wrong, the developer fixes it before the code reaches any shared environment. Strong unit tests therefore stop rounding errors, currency conversion mistakes and field mapping errors at the cheapest possible point.

System Integration Testing, known as SIT, checks that the pieces work together as a system. A pacs.008 created in the payment hub must pass through sanctions screening, reach the SWIFT gateway, receive a pacs.002 status report, and update the customer account and the general ledger. SIT proves that interfaces, message formats, queues and databases work together. A typical SIT case sends a 45,000 dollar payment from HSBC to Citibank, checks the MT103 equivalent fields, and confirms that the ledger posts a debit of 45,000 dollars and a matching credit to the nostro account.

User Acceptance Testing, known as UAT, is owned by the business and proves that the system meets real business needs. Business users run end to end scenarios that mirror production, such as a corporate treasurer at a UK retailer paying 850,000 pounds in salaries through a pain.001 file. They check the payment file, the approval workflow, the cut off warning and the camt.053 statement the next morning. UAT is not a repeat of SIT. It asks whether a real user can complete real work safely, and whether the result matches the business requirement that was originally approved.

Regression testing protects everything that already works when a change is introduced. A bank that changes its ISO 20022 mapping for pacs.008 must still prove that existing MT103 payments, SEPA payments and domestic Faster Payments continue to work. A regression pack therefore reruns a wide set of proven scenarios, including high value payments, low value payments, returns, recalls and rejected payments. If a change breaks a previously working flow, regression testing finds it before customers do, and that protection is essential in a system that processes millions of payments every day.

These four levels work as a chain, and skipping one level creates risk. A team that skips unit testing pushes simple defects into SIT, where they are slower and more expensive to fix. A team that skips UAT releases a system that is technically correct but unusable for operations staff. A team that skips regression testing risks breaking a live payment flow that customers depend on. The discipline is to run each level with clear entry criteria, clear exit criteria and evidence that can be shown to auditors, scheme managers and senior management before go live.

A worked SIT case shows the chain in action. A corporate user submits a pain.001 file with 200 salary payments worth 1.2 million pounds. SIT must prove that the hub validates the file, that each payment passes sanctions screening, that the pacs.008 messages are created correctly, that the ledger posts 200 debits and one bulk credit, and that a pacs.002 status report arrives for each payment. If the screening service is down, SIT must prove that the payments queue safely and resume when the service returns. Each of these checks needs its own test case, its own expected result, and its own evidence.

The cost of finding a defect rises sharply at each level, which is why the chain matters. A rounding error caught by a unit test costs minutes to fix. The same error caught in SIT costs hours, because the tester must reproduce it through the full chain and the developer must redeploy. Caught in UAT, it costs days, because business users must retest and sign off again. Caught in production, it costs money, reputation, and regulatory reporting. A business analyst who understands this cost curve will invest in clear requirements and early test design, because every defect found early is a defect that never reaches a customer.

Writing the test documentation is a separate skill from running the test levels, and it is taught in ch84 BA practice depth. That chapter covers Gherkin scenarios in Given When Then form, the requirements traceability matrix, and how to design a SIT pack and a UAT pack with entry criteria, exit criteria and evidence. This chapter stays with test execution: the levels themselves, what each level proves, and the cost of finding a defect at each level.

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.