Key points of this lesson, in order.
Writing a BRD and a functional specification for a payment product
What you will learn
Your objective. By the end of this lesson, you will be able to explain writing a BRD and a functional specification for a payment product and apply it to a real banking scenario.
Why it matters. For a business analyst, the specification is judged by whether the developers can build from it without asking questions.
Chapter objective: Gherkin, traceability, SIT and UAT design, negative testing, defect management, root cause analysis
Key learning points
- Business requirements document for a payment product
- Specification structure: payment lifecycle
- Exception stage requirements
- Message mapping in the specification
- Specification sign-off
- Specification precision test
Key terms
Nostro reconciliation: Reconciliation of a bank nostro account against the statement received from the correspondent bank. Operations teams match each nostro entry to a statement entry, investigate breaks, and confirm the...
Reconciliation: The process of comparing records from two sources, such as a bank statement and an internal ledger, to confirm they agree.
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.
ISO 20022 XML explorer showing Writing a BRD and a functional specification for a payment product.
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.
- 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
Which of the following best describes writing a BRD and a functional specification for a payment product?
Takeaway and next step
What to remember
The specification must also state the mapping from the internal data model to the message, because the internal model and the message are never the same.
Follow a payment through every stage, from instruction to beneficiary credit, and note where it can stop.
Open the Payment Lifecycle Simulator →
Builds on "Requirements gathering for payments: workshops, elicitation and the domain language".
Transcript and full text
Show transcript
A business requirements document for a payment product starts with the business problem, not with the solution. The problem might be that the firm cannot process SEPA Instant payments, that its straight-through processing rate is 75 percent, or that its exception handling takes three days. The BRD states the problem, the impact, the stakeholders, the scope, the constraints, and the success criteria. A BRD that starts with the solution has skipped the problem, and the solution will be wrong. The success criteria must be measurable: the STP rate will rise from 75 percent to 95 percent, or the exception handling time will fall from three days to four hours. The functional specification is the document the developers build from, and it must be precise enough to build from. For a payment product the specification is structured around the payment lifecycle: initiation, authentication, validation, enrichment, screening, routing, processing, clearing, settlement, status reporting, reconciliation, and exception handling. Each stage gets its own section, with the inputs, the processing, the outputs, the error handling, and the audit requirements. A specification that omits the exception handling for a stage is incomplete, because the exception is where the product fails. The payment lifecycle is the spine of the specification, and every requirement hangs from it. A requirement about the pacs.008 message hangs from the processing stage. A requirement about the nostro reconciliation hangs from the reconciliation stage. A requirement about the camt.056 recall hangs from the exception stage. The spine ensures that no stage is forgotten, and that the requirements are complete. A specification that is organised by screen, or by user role, will miss the stages that have no screen and no user, such as the settlement stage, which is entirely automated. Message specifications are the most technical part of the document. Each message must be specified field by field, with the field name, the format, the mandatory or optional status, the validation rule, and the error code if the validation fails. For a pacs.008 the specification must state the debtor agent, the creditor agent, the instructed amount, the settlement method, and the charge bearer, with the code set for each one. The specification must also state the mapping from the internal data model to the message, because the internal model and the message are never the same. Non-functional requirements in payments are often more important than the functional ones. The specification must state the availability target, the recovery time objective, the recovery point objective, the throughput, the maximum processing time, the data retention period, and the audit requirements. A specification that omits the recovery time objective will produce a product that cannot recover, and the first outage will prove it. Each non-functional requirement must have a target, a measurement method, and a test. The sign-off is the moment the specification becomes a commitment. The product owner, the operations lead, the compliance lead, and the technology lead must all sign, and each signature means something different. The product owner signs that the specification meets the business need. The operations lead signs that the exception handling is workable. The compliance lead signs that the screening and reporting are correct. The technology lead signs that it can be built. A specification signed by only the product owner is not signed off, it is a wish. For a business analyst, the specification is judged by whether the developers can build from it without asking questions. A good test is to give the specification to a developer who has never seen the product and ask them to estimate the work. If they cannot estimate it, the specification is not precise enough. The acceptance criteria must include a review where the developers, the testers, and the operations team confirm the specification is complete and unambiguous. Last reviewed 7 November 2026. Further reading: Karl Wiegers, Software Requirements; the International Institute of Business Analysis, A Guide to the Business Analysis Body of Knowledge; the ISO 20022 message definitions as specification sources; the EPC rulebooks as specification sources.
A business requirements document for a payment product starts with the business problem, not with the solution. The problem might be that the firm cannot process SEPA Instant payments, that its straight-through processing rate is 75 percent, or that its exception handling takes three days. The BRD states the problem, the impact, the stakeholders, the scope, the constraints, and the success criteria. A BRD that starts with the solution has skipped the problem, and the solution will be wrong. The success criteria must be measurable: the STP rate will rise from 75 percent to 95 percent, or the exception handling time will fall from three days to four hours.
The functional specification is the document the developers build from, and it must be precise enough to build from. For a payment product the specification is structured around the payment lifecycle: initiation, authentication, validation, enrichment, screening, routing, processing, clearing, settlement, status reporting, reconciliation, and exception handling. Each stage gets its own section, with the inputs, the processing, the outputs, the error handling, and the audit requirements. A specification that omits the exception handling for a stage is incomplete, because the exception is where the product fails.
The payment lifecycle is the spine of the specification, and every requirement hangs from it. A requirement about the pacs.008 message hangs from the processing stage. A requirement about the nostro reconciliation hangs from the reconciliation stage. A requirement about the camt.056 recall hangs from the exception stage. The spine ensures that no stage is forgotten, and that the requirements are complete. A specification that is organised by screen, or by user role, will miss the stages that have no screen and no user, such as the settlement stage, which is entirely automated.
Message specifications are the most technical part of the document. Each message must be specified field by field, with the field name, the format, the mandatory or optional status, the validation rule, and the error code if the validation fails. For a pacs.008 the specification must state the debtor agent, the creditor agent, the instructed amount, the settlement method, and the charge bearer, with the code set for each one. The specification must also state the mapping from the internal data model to the message, because the internal model and the message are never the same.
Non-functional requirements in payments are often more important than the functional ones. The specification must state the availability target, the recovery time objective, the recovery point objective, the throughput, the maximum processing time, the data retention period, and the audit requirements. A specification that omits the recovery time objective will produce a product that cannot recover, and the first outage will prove it. Each non-functional requirement must have a target, a measurement method, and a test.
The sign-off is the moment the specification becomes a commitment. The product owner, the operations lead, the compliance lead, and the technology lead must all sign, and each signature means something different. The product owner signs that the specification meets the business need. The operations lead signs that the exception handling is workable. The compliance lead signs that the screening and reporting are correct. The technology lead signs that it can be built. A specification signed by only the product owner is not signed off, it is a wish.
For a business analyst, the specification is judged by whether the developers can build from it without asking questions. A good test is to give the specification to a developer who has never seen the product and ask them to estimate the work. If they cannot estimate it, the specification is not precise enough. The acceptance criteria must include a review where the developers, the testers, and the operations team confirm the specification is complete and unambiguous. Last reviewed 7 November 2026. Further reading: Karl Wiegers, Software Requirements; the International Institute of Business Analysis, A Guide to the Business Analysis Body of Knowledge; the ISO 20022 message definitions as specification sources; the EPC rulebooks as specification sources.
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.