Payments Training Hub
Defect in payments PAYMENT OPERATIONS STARTED LIVE 01 Defect in payments - must be recorded with enough detail ACTIVE 02 Defect severity in payments - judged by financial and customer impact QUEUED 03 Entry criteria - define when testing can start QUEUED 04 Exit criteria - define when testing can stop QUEUED 05 Defect management - also needs a clear retest process. QUEUED A defect in payments must be recorded with enough detail for a developer to reproduce it without guessing. Step 1 of 5 Defect in payments STARTED Defect in payments must be recorded with enough detail ACTIVE Defect severity in payments judged by financial and customer impact QUEUED Entry criteria define when testing can start QUEUED Exit criteria define when testing can stop QUEUED Defect management also needs a clear retest process. QUEUED A defect in payments must be recorded with enough detail for a developer to reproduce it without guessing.
Defect severity in payments PAYMENT OPERATIONS IN PROGRESS LIVE 01 Defect in payments - must be recorded with enough detail DONE 02 Defect severity in payments - judged by financial and customer impact ACTIVE 03 Entry criteria - define when testing can start QUEUED 04 Exit criteria - define when testing can stop QUEUED 05 Defect management - also needs a clear retest process. QUEUED Defect severity in payments is judged by financial and customer impact, not only by technical difficulty. Step 2 of 5 Defect severity in payments IN PROGRESS Defect in payments must be recorded with enough detail DONE Defect severity in payments judged by financial and customer impact ACTIVE Entry criteria define when testing can start QUEUED Exit criteria define when testing can stop QUEUED Defect management also needs a clear retest process. QUEUED Defect severity in payments is judged by financial and customer impact, not only by technical difficulty.
Entry criteria PAYMENT OPERATIONS IN PROGRESS LIVE 01 Defect in payments - must be recorded with enough detail DONE 02 Defect severity in payments - judged by financial and customer impact DONE 03 Entry criteria - define when testing can start ACTIVE 04 Exit criteria - define when testing can stop QUEUED 05 Defect management - also needs a clear retest process. QUEUED Entry criteria define when testing can start, and they prevent wasted effort. Step 3 of 5 Entry criteria IN PROGRESS Defect in payments must be recorded with enough detail DONE Defect severity in payments judged by financial and customer impact DONE Entry criteria define when testing can start ACTIVE Exit criteria define when testing can stop QUEUED Defect management also needs a clear retest process. QUEUED Entry criteria define when testing can start, and they prevent wasted effort.
Exit criteria PAYMENT OPERATIONS IN PROGRESS LIVE 01 Defect in payments - must be recorded with enough detail DONE 02 Defect severity in payments - judged by financial and customer impact DONE 03 Entry criteria - define when testing can start DONE 04 Exit criteria - define when testing can stop ACTIVE 05 Defect management - also needs a clear retest process. QUEUED Exit criteria define when testing can stop, and they protect the bank from releasing too early. Step 4 of 5 Exit criteria IN PROGRESS Defect in payments must be recorded with enough detail DONE Defect severity in payments judged by financial and customer impact DONE Entry criteria define when testing can start DONE Exit criteria define when testing can stop ACTIVE Defect management also needs a clear retest process. QUEUED Exit criteria define when testing can stop, and they protect the bank from releasing too early.
Defect management PAYMENT OPERATIONS COMPLETE LIVE 01 Defect in payments - must be recorded with enough detail DONE 02 Defect severity in payments - judged by financial and customer impact DONE 03 Entry criteria - define when testing can start DONE 04 Exit criteria - define when testing can stop DONE 05 Defect management - also needs a clear retest process. ACTIVE Defect management also needs a clear retest process. Step 5 of 5 Defect management COMPLETE Defect in payments must be recorded with enough detail DONE Defect severity in payments judged by financial and customer impact DONE Entry criteria define when testing can start DONE Exit criteria define when testing can stop DONE Defect management also needs a clear retest process. ACTIVE Defect management also needs a clear retest process.

Key points of this lesson, in order.

0:00 / 2:59 Step 1 of 5

Defect Management, Entry and Exit Criteria

Payment Testing and Certification, Lesson 6 of 7, Narration 2:59, D11 Operations, exceptions and reconciliation

Sanctions screeningCharge bearerpacs.008

What you will learn

Your objective. By the end of this lesson, you will be able to explain defect management, entry and exit criteria. A defect in payments must be recorded with enough detail for a developer to reproduce it without guessing.

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

  • Defect in payments
  • Defect severity in payments
  • Entry criteria
  • Exit criteria
  • Defect management

Key terms

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

Charge bearer: A code that states who pays the charges for a payment. In ISO 20022 the values are DEBT for debtor, CRED for creditor, SHAR for shared and SLEV for service level.

pacs.008: An ISO 20022 message for a financial institution to financial institution customer credit transfer. It replaces MT103 in cross border payments and carries structured debtor, creditor, charges and...

Clearing and settlement timeline showing Defect Management, Entry and Exit Criteria.

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

Investigate the reconciliation break described in this lesson and find its root cause.

Use the three-way matching rule and the break categories in this lesson.

  1. What to do. Compare the instruction, the settlement record and the statement, name the break type, and state the corrective action.

Correct result. A break is found by matching amount, currency, date and reference across the three sources. The root cause is a timing difference, an amount difference, a missing entry, or a duplicate, and the corrective action follows the cause.

Why. Reconciliation is the last line of defence. A break that is not investigated is money that cannot be proved.

Check your understanding

Practice question

Which of the following best describes defect management, entry and exit criteria?

Takeaway and next step

What to remember

A weekly defect review, with open defects, ages and owners, keeps the team honest and ensures that no critical issue is hidden in a spreadsheet until the day before go live.

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

Open the Accounting and Reconciliation Lab →

Builds on "Test Data, Environments and Simulators".

Transcript and full text

Show transcript

A defect in payments must be recorded with enough detail for a developer to reproduce it without guessing. A good defect report includes the environment, the test case reference, the payment reference, the amount and currency, the steps taken, the expected result and the actual result. For example, a defect might state that a pacs.008 for 50,000 dollars to Citibank was created with the charge bearer set to DEBT instead of SHAR, and that the ledger posted an incorrect charge of 25 dollars. A screenshot, a message copy and a log extract help the developer find the cause quickly, and a vague report such as payment failed will waste time and delay the fix. Defect severity in payments is judged by financial and customer impact, not only by technical difficulty. A critical defect is one that moves money incorrectly, duplicates a payment, or allows a payment to bypass sanctions screening. A high severity defect is one that blocks a common payment type, such as all SEPA payments failing validation. A medium defect might affect a rarely used field, and a low defect might be a spelling error on a confirmation screen. A team must agree these definitions before testing starts, so that severity is not argued case by case when a deadline is near. Entry criteria define when testing can start, and they prevent wasted effort. Testing should not start until the code is deployed to the test environment, the test data is ready, the simulators are available, and the requirements are clear. If testing starts before the environment is stable, testers will log false defects and lose trust in the results. A simple entry checklist, signed by the test lead and the development lead, makes the decision visible and stops pressure to start testing on an unfinished build. Exit criteria define when testing can stop, and they protect the bank from releasing too early. A typical exit rule requires that all critical and high defects are fixed and retested, that all mandatory test cases have passed, that regression testing has passed, and that the business has signed UAT. A release with an open critical defect, such as duplicate pacs.008 generation, must not go live, even if the project is late. Exit criteria give the test lead the authority to say no, and that authority is essential when commercial pressure pushes for an early release. Defect management also needs a clear retest process. When a developer fixes a defect, the tester must rerun the original failing case and a set of related cases to prove that the fix works and has not broken anything else. The defect is only closed when the retest passes and the evidence is attached. A defect that is marked as fixed without a retest is still open in practice. A weekly defect review, with open defects, ages and owners, keeps the team honest and ensures that no critical issue is hidden in a spreadsheet until the day before go live. A severity matrix makes defect triage objective. A critical defect is one that moves money incorrectly, duplicates a payment, or allows a payment to bypass sanctions screening; it blocks release. A high defect is one that corrupts data or produces a wrong message format; it must be fixed before go-live. A medium defect is one that affects usability or reporting but does not move money incorrectly; it can be deferred with a documented workaround. A low defect is a cosmetic issue. Each defect report must include the environment, the test case reference, the payment reference, the expected result, the actual result, and the evidence, so that a developer can reproduce it without guessing. A defect that cannot be reproduced cannot be fixed. Entry and exit criteria protect both the tester and the bank. Testing should not start until the code is deployed to the test environment, the test data is ready, the simulators are available, and the test cases are written and reviewed. Testing should not stop until all critical and high defects are fixed and retested, all mandatory test cases have passed, and the evidence pack is complete. A typical exit rule requires zero open critical defects, zero open high defects, and a pass rate of 100 percent on mandatory cases. When a developer fixes a defect, the tester must rerun the original failing case and a set of related cases to prove that the fix works and has not broken anything else. That retest is not optional; it is the evidence that the fix is real.

A defect in payments must be recorded with enough detail for a developer to reproduce it without guessing. A good defect report includes the environment, the test case reference, the payment reference, the amount and currency, the steps taken, the expected result and the actual result. For example, a defect might state that a pacs.008 for 50,000 dollars to Citibank was created with the charge bearer set to DEBT instead of SHAR, and that the ledger posted an incorrect charge of 25 dollars. A screenshot, a message copy and a log extract help the developer find the cause quickly, and a vague report such as payment failed will waste time and delay the fix.

Defect severity in payments is judged by financial and customer impact, not only by technical difficulty. A critical defect is one that moves money incorrectly, duplicates a payment, or allows a payment to bypass sanctions screening. A high severity defect is one that blocks a common payment type, such as all SEPA payments failing validation. A medium defect might affect a rarely used field, and a low defect might be a spelling error on a confirmation screen. A team must agree these definitions before testing starts, so that severity is not argued case by case when a deadline is near.

Entry criteria define when testing can start, and they prevent wasted effort. Testing should not start until the code is deployed to the test environment, the test data is ready, the simulators are available, and the requirements are clear. If testing starts before the environment is stable, testers will log false defects and lose trust in the results. A simple entry checklist, signed by the test lead and the development lead, makes the decision visible and stops pressure to start testing on an unfinished build.

Exit criteria define when testing can stop, and they protect the bank from releasing too early. A typical exit rule requires that all critical and high defects are fixed and retested, that all mandatory test cases have passed, that regression testing has passed, and that the business has signed UAT. A release with an open critical defect, such as duplicate pacs.008 generation, must not go live, even if the project is late. Exit criteria give the test lead the authority to say no, and that authority is essential when commercial pressure pushes for an early release.

Defect management also needs a clear retest process. When a developer fixes a defect, the tester must rerun the original failing case and a set of related cases to prove that the fix works and has not broken anything else. The defect is only closed when the retest passes and the evidence is attached. A defect that is marked as fixed without a retest is still open in practice. A weekly defect review, with open defects, ages and owners, keeps the team honest and ensures that no critical issue is hidden in a spreadsheet until the day before go live.

A severity matrix makes defect triage objective. A critical defect is one that moves money incorrectly, duplicates a payment, or allows a payment to bypass sanctions screening; it blocks release. A high defect is one that corrupts data or produces a wrong message format; it must be fixed before go-live. A medium defect is one that affects usability or reporting but does not move money incorrectly; it can be deferred with a documented workaround. A low defect is a cosmetic issue. Each defect report must include the environment, the test case reference, the payment reference, the expected result, the actual result, and the evidence, so that a developer can reproduce it without guessing. A defect that cannot be reproduced cannot be fixed.

Entry and exit criteria protect both the tester and the bank. Testing should not start until the code is deployed to the test environment, the test data is ready, the simulators are available, and the test cases are written and reviewed. Testing should not stop until all critical and high defects are fixed and retested, all mandatory test cases have passed, and the evidence pack is complete. A typical exit rule requires zero open critical defects, zero open high defects, and a pass rate of 100 percent on mandatory cases. When a developer fixes a defect, the tester must rerun the original failing case and a set of related cases to prove that the fix works and has not broken anything else. That retest is not optional; it is the evidence that the fix is real.

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.