Verification of Payee Implementation

Skip key takeaways

Key takeaways: verification of payee implementation 5

Updated August 4, 2026

Who actually has to build a responder, the one number the scheme sets and where the scheme hands the matching decision to the responding PSP instead of specifying it.

• Only account-servicing PSPs must build a responder, and for them the responder role is not optional even though scheme participation is Scheme participation itself is voluntary, but an account servicing PSP that joins must take on both the requesting and the responding role, while a PSP that only initiates payments needs to build the requesting role alone. The underlying duty to run the check comes from the regulation rather than from the scheme.
• The responder shall check the requester's scheme participation in the directory. Certificate authentication alone is not conformant The Rulebook states this duty for the responder without any softening language, unlike the equivalent requester duty which is qualified. A responder that only validates the caller's certificate and stops there has not met the directory check the Rulebook requires.
• One number exists in the Rulebook, a five second round trip that belongs to the requester, and a late response must be thrown away rather than used The responder itself carries no numeric deadline in the Rulebook, only a duty to answer instantly and without delay. Because a late response has to be discarded rather than accepted, there is no way to recover a missed answer after the fact.
• The scheme mandates supporting the response types and delegates every criterion for choosing among them, to a document that says it is not part of the Rulebook and that the responder may ignore Supporting the defined response types is mandatory, but the guidance document names itself as sitting outside the Rulebook and states that the responding PSP remains free to apply its own criteria. That same guidance document also puts the liability for whichever outcome it produces on the responder.
• The Rulebook's three worked examples for a non-result answer resolve to one clean code, one status with no code and nothing at all An incorrect or incomplete account number maps cleanly to a defined error code, and the responder's own service being unavailable maps to a defined status with no code attached. For an account the responder does not hold, the specification names no matching status or code at all, which leaves that branch an open question rather than a resolved one.

Copy takeaways

If you are building either the requesting or the responding side of Verification of Payee, we can help you make every discretionary choice a documented decision rather than a default.

See our FinTech development services

A verification of payee implementation is two builds wearing one name, and the scheme treats them very differently. The requesting side is a specified round trip with one number on it and a rule that throws a late answer away. The responding side is a specified envelope around a decision the scheme declines to make for you.

In short: Under Reg (EU) 2024/886, Art 1(2), inserting Art 5c(1) into Reg (EU) No 260/2012, a payer's PSP must run the payee check immediately after the payer supplies the payee details and before authorisation is offered, on every initiation channel. Under EPC218-23 v1.1 (2026) §4.3 every account-servicing PSP is both requester and responder, and only account-servicing PSPs have to build the responder. The Rulebook sets exactly one number, a five second round trip that belongs to the requester, and binds the responder by "Instantly", glossed as "At once, without delay". Matching itself is delegated to EPC288-23 v1.0 (2024), which states that it does not form part of the Rulebook and that the responder remains entirely free to apply different criteria, and which contains no threshold, no score and no tolerance. Because the responder carries that liability for the outcome it produces, every discretionary choice in this build is a risk decision rather than an engineering preference.

Before a request exists: who has to build which role

The statutory duty lands on the payer's PSP. Reg (EU) 2024/886, Art 1(2), inserting Art 5c(1) into Reg (EU) No 260/2012, requires it to run the check "immediately after the payer provides relevant information about the payee and before the payer is offered the possibility of authorising that credit transfer", on every initiation channel, with point (d) closing the escape route for channels that never collect a name. Euro-area PSPs comply from 9 October 2025 and the rest from 9 July 2027 under Art 5c(9), while the free-of-charge rule is Art 5b(2), on its own date of 9 January 2025.

Scheme membership is a separate question, with a qualifier summaries drop. EPC218-23 v1.1 (2026) §4.1 (p.36 of 68) opens "Participation in the VOP Scheme is optional", and §4.3 then splits the roles: account-servicing PSPs "shall participate in the Scheme in the role of Requesting PSP and of Responding PSP", while other participants "shall participate ... in the role of at least Requesting PSP". Only account-servicing PSPs are obliged to build a responder, so if you already service accounts that half is not optional, which puts it on the same roadmap as how to build a neobank.

Regulation and scheme split the work here: the regulation creates the duty, the scheme creates the mechanism, so participation is voluntary while the service obligation is not, and Reachability is defined to match, reaching "all account-servicing PSPs offering SEPA credit transfer or SEPA instant credit transfers in SEPA". One inference of ours: Art 1(1) of Reg (EU) No 260/2012 confines that regulation to euro-denominated transactions, so Art 5c reaches euro credit transfers.

Before a byte moves: the directory lookup

Two directory duties fall to the requester, and they carry different force. EPC218-23 v1.1 (2026) §2.1 (p.17 of 68) says it "shall use the EDS to check the Responding PSP's participation to the scheme and may use the EDS to find the routing data". Membership is a shall, routing a may. Where the request will carry an identification code rather than a name, §3.2 adds that the requester "must verify that this data element is available in the internal system of the Responding PSP", offering the directory as the means with a "could".

One sentence carries the responder's duty, with nothing softened: "The Responding PSP shall use the EDS to check the Requesting's PSP's participation to the VOP scheme." The misplaced apostrophe is in the source. No may-clause qualifies it and no counterpart appears anywhere in EPC103-24 v1.1.1 (2026), so a responder that validates the caller's certificate and stops there is not conformant. The API sees the same condition from the far end, mapping a client with "a valid certificate but is not contained in the addressed scheme directory" to HTTP 401 with message code CLIENT_INVALID.

Underneath both roles sits one registration rule: §2.4 (p.19 of 68) makes EDS registration "mandatory for the Participants" and requires that they "shall download the current copy of the EDS". Note the asymmetry as printed rather than as remembered. For the requester, checking participation is a shall and routing a may. For the responder, checking participation is a shall standing alone.

What arrives on the wire

Bulk exists on the requester's side and nowhere else. Section 3.2 (p.21 of 68) is blunt about it: where several account numbers are to be verified, the requester "must then send a VOP Request in the Inter-PSP Space for each Payment Account Number concerned". One mandatory endpoint takes each of them, a POST to /vop/v1/payee-verifications, with X-Request-ID and X-Request-Timestamp as headers. That single endpoint sits inside a much larger integration surface, which is the same accounting problem as payment gateway integration cost.

Nine attributes arrive at the responder, of which only C007 is optional and only E013 conditional, so it may treat the rest as always present. The rule that produces real defects is in DS-02's Rules applied row (§3.5.2, pp.28-29 of 68): the name and the identification code "are mutually exclusive". A request carrying both is malformed, and catching it is the responder's job under §4.8 point 7, which requires it to "Validate the syntax of the VOP Request ... and provide the Requesting PSP with an appropriate reason code if the VOP Request is invalid or incomplete".

One line of DS-02 governs how both sides read the dataset chapter. Its Remarks row states that these attributes "do not prescribe fields in the VOP Scheme Inter-PSP API specifications", so a mapping built by matching AT-numbers to JSON field names by eye will drift. And from 20 September 2026, EPC103-24 v1.1.1 requires every Max*TextVop string to be at least one character long, so empty-string values are non-conformant.

The clock

One number exists and it belongs to the requester. EPC218-23 v1.1 (2026) §3.3.2 B (p.22 of 68): "The maximum execution time for the Requesting PSP to get the VOP Response is 5 seconds (preferably 1 second or less)." At the end of the same section, p.23 of 68, sits one sentence often implemented backwards: "If the Response is received after the reply to the Requester has been provided, the Requesting PSP must discard that Response."

No number binds the responder in that document at all. Section 4.8 point 3 (p.41 of 68) sets a qualitative duty instead, to "Be able to Instantly process VOP Requests and Instantly initiate VOP Responses ... 24 hours a day on all Calendar Days of the year", with no uptime target attached, and point 4 requires the answer "within the time defined in section 3.3.2", the requester's envelope. "Instantly" is a defined term in Chapter 6, glossed "At once, without delay". Over the complete 68-page extracted text, a case-insensitive search returned no occurrence of timeout, time out, retention, retain, logging, audit trail, record keeping, non-conform, penalt or uptime, and every occurrence of seconds is that same five second figure. That is a finding about the published text of EPC218-23 v1.1 and nothing wider, because Annex II is EPC305-24, which "has a restricted distribution and is therefore not included here".

Both sides stamp time, and the floor is stricter in the Rulebook than in the API. AT-T061 (§3.6.1, p.34 of 68) says the response timestamp "must be unambiguous and at least include milliseconds", AT-T056 says it of the request, and EPC103-24 v1.1.1 §4.2.9.1 requires a timezone indicator while saying nothing about precision. A second-precision ISO 8601 timestamp therefore passes the API specification and fails the Rulebook. There is no responder-side deadline to breach, and no way to recover a missed one, because a late answer must be thrown away rather than used.

The decision

The requester never sees the decision, only its result, and has no scheme mechanism for asking which criteria fired. Its only leverage is retrospective: §4.8 point 8 (p.42 of 68) requires the responder, "In the event of a dispute", to "provide the Requesting PSP with an explanation as to how a VOP Request has been processed". The shortness of that paragraph is the argument.

What EPC288-23 says about itself

Everything else here belongs to the responder. The Rulebook names three outcomes and never computes them, deferring three separate times to reference [6], which is EPC288-23. Open that document and the first thing it says is what it is not:

It does not form part of the VOP Scheme Rulebook, but it provides guidance to the Responding PSP ... The Responding PSP bears the full responsibility for the matching outcome and therefore remains entirely free to apply different criteria ... It is mandatory for the Responding PSP to support all the response types specified in the VOP Scheme Rulebook and the related reason codes (Match, No Match, Close Match,…).

That is EPC288-23 v1.0 (2024), §I, p.1 of 5, and it splits the build cleanly. Supporting the response types is mandatory; every criterion for choosing among them is not. The verb pattern agrees, since shall occurs zero times in the whole five-page document and must exactly once, and the document declares itself written against Rulebook v1.0 while the Rulebook in force is v1.1 of 16 March 2026.

Preparing the name for comparison

Before comparison the responder prepares the name, and §II section 0 (p.2 of 5) offers five examples rather than a specification. Two read counterintuitively. The diacritics rule is conditional with an inverted default, "Change diacritics/accents unless the Responding PSP is able to compare" against the Latin characters defined in EPC217-08, so a responder with full Unicode comparison capability is told not to fold. And the equivalences printed there, "ö = o = ø = oe ; ä = a = æ = ae ; å = a = aa ; é = e = ee", are one to many, so an implementation built on Unicode decomposition plus combining-mark stripping produces the first branch of each and never the second. EPC217-08 was not read here, so nothing states which characters that subset contains.

Two contradictions in the criteria

The document then says two incompatible things about the criteria themselves. One paragraph presents the scenarios as "the minimum criteria" for deciding whether a provided name "might be considered as a Close Match, or not". Three paragraphs later: "these scenarios should be used as guidelines only, each Responding PSP maintains the discretion to apply additional criteria". A minimum criterion is a floor a responder may not go below. A guideline is not. Both sit in §II section 2, p.3 of 5, and neither is reconciled.

The two scenario lists are asymmetric in a way that is invisible unless they are read side by side. Word order and "commonly accepted abbreviations" are offered for legal persons only, the first-initial rule for natural persons only, so "Jones, Robert" against "Robert Jones" has no listed Close Match scenario while a reordered company name does. No legal-form suffix rule exists at all: a search of the complete text returned zero hits for suffix, legal form, Ltd, GmbH, SARL and PLC.

No threshold, no score

And there is no threshold. The one place a number could sit reads "If the spelling mistake does not exceed the defined level set by the Responding PSP ... (e.g., Levenshtein distance)", making the level the responder's own parameter and Levenshtein a parenthetical example. A case-insensitive search of the complete five-page text for threshold, score, percentage, tolerance, fuzzy, algorithm, Jaro, Soundex, normalisation, normalization and transliteration returned zero occurrences of every term, and Levenshtein occurs twice, both inside that parenthesis. That is a statement about EPC288-23 v1.0, not about the VoP scheme, since EPC305-24 is restricted and EPC217-08, EPC164-22, EPC267-24 and EPC139-25 were not read. The lone must is not a metric either: "the length of the names must also be taken into account when determining a small deviation", with no function, no scale and no worked example.

The liability and the schedule

So the contract here is lopsided by design, and the pairing that follows is stated three times in five pages: "it is at the discretion of each Responding PSP to determine whether a matching result is a Match, Close Match or a No Match. The Responding PSP takes up the liability for providing such Response to the Requesting PSP." Those recommendations "can be reviewed outside the regular VOP Scheme Rulebook change management cycle", applying "at the earliest 90 calendar days after the publication of the updated version" or sooner in an emergency, and only responding PSPs may propose changes, "as only they perform the matching actions". The criteria you are held to move on a schedule your counterparties cannot influence.

The answer that is a matching result

Four wire codes come back to the requester on one of two fields. EPC103-24 v1.1.1 (2026) §4.2.5 (p.22 of 37) sets the name-side value set, MTCH, NMTC, CMTC and NOAP, while §4.2.6 carries three, without CMTC. The two match fields carry an exclusive-choice brace notation, and matchedName "must be provided if and only if the result of partyNameMatch is "Close Match"". All of these ride HTTP 200, since §4.3.1 states that a successful process may return a positive or a negative response and that in either case "the HTTP response code will be 'HTTP Code 200 - OK'". A No Match is a successful API call.

On the responder's side the exclusivity is a dataset rule before it is a wire rule. In DS-03 (§3.5.3, pp.29-30 of 68) R001 is conditional on the name having been sent and R011 on the identification code, and since those two are mutually exclusive, exactly one of them appears in a conformant response. Close Match lives on the name combination alone, because AT-R010 is "limited to Close Match only" and keys off AT-R001 while AT-R011 has no Close Match value. On a joint account, §1.3 (p.13 of 68) is scheme rules rather than guidance: the responder supplies only name information about the counterparty named in the request, and "does not disclose the name of any other payment account holder(s) assigned to that Payment Account Number". Returning the registered account title verbatim leaks a co-holder.

Both documents agree on the matrix. The Rulebook's normative enumerations, AT-R001, AT-R011 and Table 1, hold exactly four distinct result names and those map one to one onto the four wire codes; a fifth name, "Identification code not supported/known by the Responding PSP", appears in narrative prose but in no value range and no glossary entry. Annex III records v1.1 removing one matching result as a typo fix without saying which, so nobody should assert it. Both match elements are flagged "Future ISO code expected", so these values do not resolve against an ISO 20022 external code list today.

The answer that is not a matching result

Here the requester's job is narrow. Under §3.2.1 (p.21 of 68) it "reports the received VOP Response unaltered to the Requester as appropriate", and on the API it parses a second shape entirely: successful responses use application/json, error responses application/problem+json under RFC 7807, of whose six fields only type and code are mandatory. Two disjoint shapes, not one shape with a status field. Only four HTTP statuses are defined, 200, 400, 401 and 500, so a responder returning 404 for an account it does not hold is emitting a status the specification does not define.

The load-bearing rule, and its two meanings

At this position the responder's duty is the load-bearing rule of the Rulebook, and it uses a phrase that means the opposite of what it means in the API specification:

In case the Responding PSP is not in the position to produce a matching result due to reasons other than those linked to a verification of the combination of the information attributes requested (e.g., incorrect or incomplete Payment Account Number, Payment Account Number not maintained by the Responding PSP, VOP service not available, etc), the Responding PSP provides the Requesting PSP with an accurate reason code (refer to the VOP Scheme Inter-PSP API Specifications [1]).

In that sentence, EPC218-23 v1.1 (2026) §3.2.1, p.21 of 68, "reason code" means what you send instead of a matching result, while EPC103-24 v1.1.1 §4.3.1 uses the same phrase for the matching outcome itself. What follows names the artefact instead: the partyNameMatch value or the code field of the RFC 7807 error body. A responder answering "no match" to "not my account" is answering a question nobody asked.

Tracing the three worked examples

Trace the three worked examples into EPC103-24 v1.1.1 and they resolve unevenly. An incorrect or incomplete account number maps cleanly, to "Invalid field's value" with the example "Malformed IBAN", FORMAT_ERROR, HTTP 400. The responder's own service being down maps partly, to an "Internal Server Error" row at HTTP 500 with no message code assigned, while code is mandatory. An account number the responder does not service maps to nothing: a case-insensitive search of the complete text for not maintained, not serviced, unknown account, account not, IBAN not, not found, 404, unavailable, service not, maintenance and SERVICE_ returned zero hits for every term. Document-scoped and fenced the same way, because EPC305-24 is restricted and EPC267-24 and EPC139-25 were not fetched.

Two branches, no recommendation

So the contract at this position has a hole in it, and the useful thing is its shape rather than a filled-in answer. One branch is NOAP on HTTP 200, which cases 1.4 and 2.3 appear to license by reading "Matching not possible for the responding application for any reason"; its cost is that the Rulebook says this class of condition is expressly not a matching result, so the answer misdescribes itself. The other is HTTP 400 with FORMAT_ERROR, given a precedent by the Note at §4.2.6 routing an unsupported identification code to a 400; its cost is that a well formed IBAN belonging to another PSP is not a format error. The error-cases table is expressly non-exhaustive, "The table below shows some error cases identified", so neither branch is prohibited, and a requester's directory check only thins the frequency, since EDS participation is per PSP and not per IBAN. Whichever branch a responder picks, it is picking, and the specification did not tell it to.

After the answer: the payer's screen and the liability chain

On the requesting side the result becomes a screen. On a mismatch the payer's PSP must warn that authorising "might lead to transferring the funds to a payment account not held by the payee indicated by the payer"; where the two almost match it "shall indicate to the payer the name of the payee associated with the payment account identifier", so that branch alone discloses a name. Art 5c(5) sets the design constraint, since the service must not "prevent payers from authorising the credit transfer concerned", and the Art 5c(6) opt-out is doubly conditioned rather than a corporate exemption, being open to users that are not consumers and only "when submitting multiple payment orders as a package". Carrying this onto one register is the job of a FinTech compliance checklist.

On the responding side the exposure is capped, and the cap is unusual. Section 4.9.2 (p.43 of 68) limits a claim to "the amount of the Payment Account-based Payment related to the specific VOP Request", applies that cap "even if there has been gross negligence" and lifts it only for wilful intent. Measured against the payment rather than the check, exposure scales with the transactions a responder fails to verify, and outsourcing does not move it: "A Participant uses the services of an RVM at its own risk under its sole responsibility".

The two chains meet in the regulation. Under Art 5c(8) a PSP "shall not be held liable ... on the basis of an incorrect unique identifier, as laid down in Article 88 of Directive (EU) 2015/2366, provided that it has fulfilled the requirements of this Article". Where it has not, the payer's PSP refunds without delay and restores the debited account, then recovers from the payee's PSP or the payment initiation service provider that caused the failure. It pays first regardless of fault, and Art 5c(5) is what makes that coherent: the check is advisory, so liability follows performance of the check rather than the customer's decision to proceed. As agreed text not yet law, the draft PSR defers both the matching-verification duty and the liability provision to 27 months against a general 21 (Council doc 8221/26, p.428).

Conformance evidence a VoP build should be able to produce

The conformance evidence set below is our engineering view rather than a scheme requirement, and every obligation behind it is cited above. A finished build should answer five questions without opening a ticket. What happened to this specific request, in enough detail to satisfy the dispute explanation duty, although no retention period appears in the published Rulebook text. What time each leg stamped, at millisecond precision and in the timezone form the API requires. Whether directory participation was checked on the inbound path, evidenced separately from certificate validation. Which version of the matching criteria produced a given Close Match, so a change made on 90 days notice can be replayed against past decisions. And why the unknown-account branch behaves as it does, recorded as a decision, because it was chosen and not specified.

Availability is the one target the scheme hands back without a number, since a responder is bound by "Instantly" and a 24 hours a day duty with no uptime figure attached. Across seven client projects between 2019 and 2026 our delivery teams agreed formal service level objectives, five at 99.9 per cent monthly availability and two at 99.95 per cent for critical APIs and transactional flows. That is our own delivery record, not a scheme figure or an industry benchmark. Where this work reaches the ledger, the initiation channel and an inbound API at once, it is payment solutions development rather than a compliance line item.

How Pharos Production helps

Pharos Production builds both roles as one system with two conformance surfaces, starting with the responder because that is where the discretion and the liability sit. That means a matching layer whose criteria are versioned and replayable, a directory check wired as a first-class inbound gate rather than a side effect of TLS, timestamps at the precision the Rulebook asks for rather than the precision the API tolerates, and a written decision on the unknown-account branch with its cost stated. On the requesting side we treat the discard rule and the five second envelope as test cases rather than configuration. This is FinTech development services work on live payment rails.

Sources: Regulation (EU) 2024/886 as published (CELEX 32024R0886) and Regulation (EU) No 260/2012 in its consolidated version in force from 8 April 2024 (CELEX 02012R0260-20240408), for Articles 1(1), 5b and 5c. EPC218-23 Verification Of Payee Scheme Rulebook, 2026 Version 1.1, issued 16 March 2026 and effective 20 September 2026 at 03:30:00.000 CET, 68 printed pages, sections 1.3, 2.1, 2.4, 3.2, 3.2.1, 3.3.2, 3.5.2, 3.5.3, 3.6.1, 4.1, 4.3, 4.8, 4.9.2 and Annexes II and III. EPC103-24 VOP Scheme Inter-PSP API Specifications, 2026 Version 1.1.1, cover date 4 May 2026 and effective 20 September 2026, 37 printed pages, sections 4.1.1, 4.1.2.1, 4.1.3.3, 4.2.5, 4.2.6, 4.2.8, 4.2.9.1, 4.3.1 to 4.3.3, 4.4 and 4.5; its change history row records 30/04/2026 against the cover's 4 May 2026. EPC288-23 EPC Recommendations for the Matching Processes under the VOP Scheme Rulebook, Version 1.0, dated 10 October 2024, 5 printed pages, sections I to V, which states no effective date and declares itself written against Rulebook version 1.0. Council document 8221/26, page 428, for the draft PSR application dates, a LIMITE compromise text whose dates are placeholders and whose article numbers will move. Every EPC quote carries its document version. Absence findings are scoped to the document searched and to nothing wider: Annex II of the Rulebook is EPC305-24, which has restricted distribution and is not published, and EPC217-08, EPC164-22, EPC267-24 and EPC139-25 were not read. Source-side typographic faults inside quotation marks are reproduced as printed. The conformance evidence set, the reading of the clean-up examples and the currency-scope inference on Article 5c are ours. This is engineering guidance, not legal advice.

FAQ

Last updated: August 4, 2026 · Reviewed by: Dmytro Nasyrov (Founder and CTO)

Quick answers to common questions about custom software development, pricing, process and technology.

Expand all Collapse all

Search FAQs

Popular

Type to filter questions and answers. Use Topic to narrow the list.

Showing all 7

• ★ Featured question. Who has to build a Verification of Payee responder?

  Copy link Copies a direct link to this answer to your clipboard.

  Every account-servicing PSP. Under EPC218-23 v1.1 (2026) §4.3, participants that are account-servicing PSPs shall participate in both the Requesting PSP and the Responding PSP roles, and participants that are not account-servicing PSPs shall participate in at least the Requesting PSP role.

  Participation in the scheme itself is optional; the underlying service obligation comes from the regulation.

• What matching threshold does the VoP scheme set?

  Copy link Copies a direct link to this answer to your clipboard.

  None. The scheme delegates matching guidance to EPC288-23 v1.0, which states that it does not form part of the VOP Scheme Rulebook and that the Responding PSP remains entirely free to apply different criteria.

  A case-insensitive search of that complete five-page document for threshold, score, percentage, tolerance, fuzzy, algorithm, Jaro and Soundex returns no occurrence of any of them, and Levenshtein distance appears twice, both times as a parenthetical example of a technique. That is a finding about that document. Annex II of the Rulebook, EPC305-24, has restricted distribution and was not read.

• Is a No Match an error response?

  Copy link Copies a direct link to this answer to your clipboard.

  No. Every matching outcome, including Verification check not possible, is delivered with HTTP 200 and a response body. HTTP 400, 401 and 500 signal an API error and carry an application/problem+json body instead.

  The two are disjoint response shapes.

• What should a responder return when the IBAN is not one of its own accounts?

  Copy link Copies a direct link to this answer to your clipboard.

  The Rulebook says this is not a matching-result case and requires an accurate code from the API specification instead, giving "Payment Account Number not maintained by the Responding PSP" as one of three worked examples. EPC103-24 v1.1.1 defines no message code, no error case and no HTTP status for that condition.

  The specification's error-cases table is expressly non-exhaustive, so neither available branch is prohibited, and whichever a responder picks it is making a choice the documents did not make for it.

• How long does a responder have to answer?

  Copy link Copies a direct link to this answer to your clipboard.

  EPC218-23 v1.1 sets one number in 68 pages, a 5 second maximum for the Requesting PSP to get the response, preferably 1 second or less, and it belongs to the requester, who decides how to measure it. The responder is bound by "Instantly", defined as "At once, without delay", and by the requirement to answer within that same envelope.

  A response arriving after the requester has already replied to the Requester must be discarded, so a responder cannot recover a missed deadline by answering late.

• Can a Close Match response return the full account title?

  Copy link Copies a direct link to this answer to your clipboard.

  No. Where several account holders exist, the Responding PSP provides only name information about the Payment Counterparty as mentioned in the VOP Request and does not disclose the name of any other payment account holder assigned to that account. Returning the registered account title verbatim leaks a co-holder's name.

• Does Verification of Payee stop a payer from sending the payment?

  Copy link Copies a direct link to this answer to your clipboard.

  No. PSPs must ensure that performing the service does not prevent payers from authorising the credit transfer concerned. The check is advisory, and that is what makes the liability allocation work: where a PSP has fulfilled the article's requirements it keeps the Article 88 PSD2 shield, and where it has not, the payer's PSP refunds the payer without delay and then recovers from the payee's PSP or the payment initiation service provider that caused the failure.

I work with startup founders who need a dedicated software development team but don’t want to gamble on hiring, random outsourcing, or opaque delivery.
Most founders face the same problem sooner or later.
Early technical and team decisions lock the product into tech debt, slow delivery, missed milestones and constant re-hiring. By the time this becomes visible, fixing it is already expensive.

As a CTO and software architect, I help founders design, build and run dedicated development teams that work as a true extension of the startup. Not as a black-box vendor.

My focus is on complex products where mistakes are costly:

• Web3 and blockchain platforms
• FinTech and regulated products
• High-load startup systems
• MVP → scale transitions

We don’t do body-shopping.
We don’t sell generic outsourcing.

Instead, we help founders:

• build the right team structure from day one
• keep technical ownership and transparency
• scale delivery without losing control
• avoid vendor lock-in and hidden risks

Teams are aligned with the product roadmap, business goals and long-term architecture. Not just short-term velocity.