From Regulation to Backlog
Breaking Verification of Payee down into user stories
As a business analyst on payment programmes, my time is usually spent between two documents that were never written for each other: a regulation drafted by lawyers and a backlog read by developers and testers. Verification of Payee (VoP) under the Instant Payments Regulation is a good example of how to bridge them. The legal text is short, but it describes a feature that touches every payment channel, two different banks and a liability model. This article shows the method we use to turn it into stories and acceptance criteria a team can build and test from, covering both sides of VoP: the bank asking the question and the bank answering it.
Step 1: read the regulation as a list of obligations
Regulation (EU) 2024/886 inserts Article 5c into the SEPA Regulation. Before writing a single story, I rewrite the article as a list of atomic obligations, each with its source paragraph, the party responsible and the type of requirement:
O1. Verify before authorisation, in every channel. The payer's PSP offers verification before the payer authorises a credit transfer, immediately after the payee details are entered. (Art. 5c(1) · Payer's PSP · Functional)
O2. Act on the result. If the IBAN and name match, the payment proceeds. If they almost match, the payer is shown the name held for that IBAN. If they don't match, the payer is notified. (Art. 5c(1)(a) · Payer's PSP · Functional and UX)
O3. Verify legal-person identifiers. For legal persons, identifiers such as an LEI or fiscal number are verified where the channel accepts them. (Art. 5c(1)(b) · Both PSPs · Functional)
O4. Never block the payment. Verification must not prevent the payer from authorising the transfer. (Art. 5c(5) · Payer's PSP · Functional)
O5. Allow a bulk opt-out. Non-consumers submitting multiple orders as a package can opt out of verification, and opt back in at any time. (Art. 5c(6) · Payer's PSP · Functional)
O6. Warn and explain liability. The payer is warned that funds may go to the wrong account and told the liability consequences of continuing. (Art. 5c(7) · Payer's PSP · UX and legal content)
O7. Answer verification requests. The payee's PSP verifies the details when the payer's PSP asks. (Art. 5c(1) · Payee's PSP · Functional)
O8. Charge nothing. The service is provided free of charge. (Art. 5b(2) · Payer's PSP · Commercial)
This list is the most valuable artefact in the whole exercise. Compliance can review it in an hour, and every story we write later links back to one or more of these obligations.
Step 2: separate law, scheme and bank decisions
The regulation says what must happen. It doesn't say how two banks exchange the request, what counts as "almost matching" or how a mobile app should word a warning. Those answers come from two other layers, and I tag every requirement with the layer it comes from:
Law (IPR): the obligations above. These are not negotiable.
Scheme (EPC Verification Of Payee Scheme Rulebook): the four standard results (Match, Close Match, No Match and Verification Not Possible), the inter-PSP request and response flow, response-time limits, and matching recommendations. These are mandatory for scheme participants.
Bank policy: the exact matching rules within the scheme's guidance, the warning text, how each channel shows results, and what happens when verification isn't possible. These are decisions the bank owns and must document.
Tagging matters because the layers change at different speeds. The EPC updates its rulebook regularly, while a regulation changes rarely. When a new rulebook version arrives, the team can filter the backlog to the scheme layer and see exactly what needs reviewing.
Step 3: two epics, two perspectives
VoP has two sides, and they belong in separate epics because they have different users, different systems and different failure modes.
Epic A: Requesting PSP (our customer is paying)
As a retail customer, I want to see whether the name I entered matches the account holder before I confirm a transfer, so that I don't send money to the wrong person. (O1, O2)
As a retail customer, I want to see the account holder's name when my entry is close but not exact, so that I can correct it or continue knowingly. (O2)
As a customer who receives a No Match result, I want to still be able to authorise the payment after a clear warning, so that the decision stays mine. (O4, O6)
As a corporate treasurer submitting a payment file, I want to opt out of verification for bulk submissions and opt back in later, so that our automated processes keep running. (O5)
As a compliance officer, I want every VoP result and the customer's decision stored against the payment, so that we can show we met our obligations if the payment is disputed. (O6, liability under Art. 5c(8))
Epic B: Responding PSP (another bank asks about our customer's account)
As the bank holding the account, I want to answer VoP requests for our IBANs using the agreed matching rules, so that payers at other banks get a reliable result. (O7)
As the bank holding the account, I want to reveal the account holder's name only in a Close Match response, so that we don't disclose personal data unnecessarily. (O2, data minimisation)
As the bank holding the account, I want to verify LEI or fiscal numbers for business accounts when they are included in the request, so that business payees can be verified reliably. (O3)
The compliance story in Epic A is the one teams most often miss. The regulation states that a PSP that complies with Article 5c is not liable for a transfer sent on the basis of a wrong identifier. Proving compliance therefore depends on evidence, and evidence needs requirements of its own.
Step 4: Acceptance criteria developers and testers can work from
Each story gets acceptance criteria written in Gherkin. The aim is that a tester can automate them directly and a developer can't misread them. Here are three examples from the requesting side:
Feature: Verification of Payee before authorising a SEPA credit transfer
Scenario: Close Match shows the name held for the IBAN
Given a retail customer is creating a SEPA credit transfer in the mobile app
And they enter the IBAN "DE89370400440532013000" and the name "Jon Smith"
When the payee's PSP returns "Close Match" with the name "John Smith"
Then the app shows "John Smith" as the name held for this account
And the customer can update the payee name or continue with the transfer
And the VoP result and the customer's choice are stored against the payment
Scenario: No Match warns but does not block authorisation
Given the payee's PSP returns "No Match"
When the result is shown to the customer
Then the warning text approved by Legal (ref. VOP-UX-02) is displayed
And the liability information (ref. VOP-UX-03) is displayed
And the "Confirm transfer" action remains available
Scenario: Verification not possible
Given the payee's PSP does not respond within the scheme's maximum response time
When the result is shown to the customer
Then the app states that the name could not be verified
And the customer can still authorise the transfer after the warning
And from the responding side:
Scenario: No Match does not disclose the account holder's name
Given IBAN "DE89370400440532013000" is held by "Maria Ionescu"
When a VoP request arrives for that IBAN with the name "Andrei Pop"
Then the response result is "No Match"
And the response contains no account holder name
Three details make these criteria workable:
Text is referenced, not repeated. Warning and liability wording lives in a content register approved by Legal. Acceptance criteria point to it by ID, so a wording change doesn't require changing the tests.
Scheme values are referenced, not hard-coded. "The scheme's maximum response time" points to the rulebook. If the EPC changes the value, the criterion is still correct.
Matching rules have their own specification. Whether "Ștefan Popescu" matches "Stefan Popescu", or "SC Exemplu SRL" matches "Exemplu S.R.L.", is decided in a separate matching rules document with numbered rules and example tables. Responding-side acceptance criteria refer to those rule numbers.
Step 5: capture what the regulation doesn't say
The legal text is silent on several things the team still has to build. I keep them as explicit non-functional requirements so they aren't discovered during testing:
Performance: the check must run "immediately" in the customer journey. That means a latency target for the requesting flow and a response-time target for the responding service that sits comfortably within the scheme limit.
Availability and fallback: what the customer sees when our VoP service, the routing service or the other bank is unavailable, and how often this is monitored.
Audit and retention: how long VoP evidence is kept, aligned with the bank's complaint and dispute handling periods.
Data protection: a short GDPR assessment of what the responding service discloses, and to whom.
Every channel: web, mobile, branch (where the payer is present) and payment initiation services. "Every channel" in O1 means a story per channel, not one generic story.
Traceability: the part auditors look at
The final artefact is a traceability matrix linking each obligation to its stories, acceptance criteria and test results. It looks bureaucratic, but in practice it is what lets the bank answer a supervisor's question in a day rather than a sprint. It also tells the team exactly which tests to rerun when the regulation, the rulebook or a bank policy changes.
Closing thought
The method isn't specific to VoP: decompose the text into obligations, tag each requirement with its source layer, write stories from each party's perspective, and make acceptance criteria precise enough to automate. VoP is a timely example. Euro-area PSPs had to comply by 9 October 2025, and PSPs in non-euro member states, Romania included, must comply by 9 July 2027. For those banks, a clear backlog built now is the most reliable way to reach that date with evidence of compliance in hand.
