Requirements gathering for payments: workshops, elicitation and the domain language

Requirements gathering in payments starts with the domain language, not with a template. A payments business analyst must know what a pacs.008 is, what a nostro account is, what straight-through processing means, and what a reason code is, before they can ask a useful question. A workshop where the analyst does not know the domain language will produce requirements that are vague, wrong, or missing the exception paths. The analyst's first job is therefore to learn the domain, and the second is to teach it to the stakeholders who do not know it. Elicitation in payments uses workshops, interviews, document analysis, and observation, and each has a place. A workshop is best for agreeing the payment flow, because the flow crosses teams and the teams must agree on it together. An interview is best for understanding a single role, such as the sanctions analyst who triages alerts, because the detail is in the individual's work. Document analysis is best for the rulebook, the scheme messages, and the existing specifications, because the answers are already written down. Observation is best for the operations team, because what they do is different from what they say they do. The five Ws are the analyst's checklist for every requirement. Who initiates the payment, who approves it, who receives it, and who handles the exception. What is the payment type, what is the amount, what is the currency, and what is the message format. When is the cut-off, when is the value date, and when is the status reported. Where does the payment go, which correspondent, which clearing system, and which settlement account. Why does the payment exist, what business need does it serve, and what happens if it does not happen. A requirement that cannot answer the five Ws is not a requirement, it is a guess. Stakeholders in payments are more numerous than in most domains. The product owner wants the feature. The operations team wants the exception handling. The compliance team wants the screening and the reporting. The technology team wants the architecture. The correspondent bank wants the message format. The scheme wants the rulebook compliance. The regulator wants the audit trail. The analyst must identify every stakeholder, must understand what each one needs, and must resolve the conflicts between them, because the conflicts are real and will not resolve themselves. The workshop agenda for a payment feature is structured around the lifecycle. The first session covers initiation: who initiates, how they authenticate, what they enter, and what validation happens. The second covers processing: screening, routing, enrichment, and the message. The third covers clearing and settlement: which system, which account, and which cut-off. The fourth covers exceptions: rejects, returns, recalls, and investigations. The fifth covers reporting: status, reconciliation, and the audit trail. A workshop that covers only the happy path will produce requirements that fail in production. The output of elicitation is a set of requirements that are specific, measurable, achievable, relevant and time-bound, and each one must be traceable to a stakeholder and to a business need. A requirement that says the system must process payments quickly is not specific. A requirement that says the system must process a SEPA credit transfer within 10 seconds of receipt, 99 percent of the time, is specific, measurable, and testable. The analyst must write requirements that a tester can test, because a requirement that cannot be tested cannot be proven. For a business analyst, the elicitation is judged by the gaps it finds. A good elicitation finds the exception that nobody mentioned, the cut-off that nobody knew, and the correspondent that nobody had considered. The acceptance criteria must include a test where the requirements are reviewed by the operations team, the compliance team, and the technology team, and each team confirms the requirements cover their needs. Last reviewed 7 November 2026. Further reading: the International Institute of Business Analysis, A Guide to the Business Analysis Body of Knowledge; Karl Wiegers, Software Requirements; the European Payments Council rulebooks as elicitation sources; the SWIFT message usage guidelines.