EPC Updates Payee Verification API and Security Rules Ahead of Non-Euro EU Providers’ July 2027 Deadline
Oct. 26, 2026 • Deep Dive • Banking & Payments
The European Payments Council implemented Version 1.1 of its Verification of Payee scheme rulebook on September 20, 2026, clarifying operations, API specifications and security after feedback from live deployment. Its directory service, operated with SWIFT, has also completed a live transition supporting provider reachability and routing. The changes come as non-eurozone EU payment providers work toward a July 9, 2027, compliance deadline.
Required under the EU Instant Payments Regulation for both instant and standard SEPA credit transfers, Verification of Payee checks recipient details before authorization and must be offered free to users. The inter-provider exchange has a five-second operational maximum and can return a match, close match, no match or verification-not-possible result. A close match supplies the verified recipient name for the payer to review. A warning does not necessarily prevent a transfer: liability depends on whether a payer proceeds despite it or a provider fails to perform a required check.
The European Payments Council (EPC) implemented Version 1.1 of its Verification of Payee (VoP) scheme rulebook on September 20, 2026, adding operational clarifications and updates to its API specifications and security framework after feedback from live deployment. The changes concern a check designed to show payers whether the recipient details they entered correspond to the intended account before they authorize a transfer.
The update comes as payment service providers in non-eurozone EU countries work toward a July 9, 2027, statutory compliance deadline. Providers in the euro area faced an earlier milestone on October 9, 2025. Under Regulation (EU) 2024/886, known as the Instant Payments Regulation, providers must offer the check free of charge to payment service users for both instant and standard SEPA credit transfers.
How the Check Works
Verification of Payee compares the recipient information supplied by a payer with information held for the destination account. The sending, or Requesting, payment service provider asks the receiving, or Responding, provider to validate the details before the payment is authorized. The inter-provider communication loop has an operational maximum service-level agreement of five seconds, making its speed significant for transfers that users expect to initiate in real time.
The scheme uses four standardized responses: Match (MTCH), Close Match (CMTC), No Match (NMTC) and Verification Not Possible (NOAP). They tell the Requesting provider what the Responding provider could establish, rather than replacing the payer’s decision about whether to proceed. A No Match or Close Match result gives the payer a warning to consider before authorizing the transfer.
A Close Match triggers an additional disclosure. The Responding provider sends back the verified name registered to the IBAN, allowing the Requesting provider to present that name directly to the payer for review. This gives the payer a more specific basis for checking a near match than a warning alone would provide. The check can expose a discrepancy in the details entered, but it does not guarantee that a payer will stop a transfer after seeing one.
For business and corporate recipients, the regulation also permits identification using non-name identifiers, including Legal Entity Identifiers, European Unique Identifiers and national Value-Added Tax identification numbers. These provide permitted alternatives to a recipient-name check in the relevant circumstances.
Rules, Routing and Responsibility
The EPC Directory Service, built and operated in partnership with SWIFT through swiftrefdata.com and api.swift.com, has completed its live transition. It supports reachability and routing lookups for compliant payment service providers and Routing and Verification Mechanisms. Those lookups help participants direct verification requests to the appropriate destination; they are distinct from the Responding provider’s assessment of whether the payee details match.
The scheme does not prescribe one mathematical method for determining a close match. Each Responding provider decides how to set its matching threshold and handle issues such as diacritics or transliteration between writing systems. That discretion leaves providers responsible for their own matching determinations, even though they return results using the same four response codes.
The distinction between a warning and a failed check matters for liability. Under Article 5c of the regulation, a payer who authorizes a transfer after receiving a No Match or Close Match warning assumes liability for that discrepancy, rather than the sending provider bearing refund liability for it. If a sending provider fails to deliver the mandatory check before authorization, or a Responding provider supplies incorrect validation data, the liable institution must refund the customer without delay.
Corporate entities submitting batch or bulk payments through file-based electronic payment orders may contractually opt out of real-time VoP checks. That exception does not change the general requirement to offer verification to payment service users across both instant and standard SEPA credit transfers.
Next Steps for Providers
The EPC is scheduled to publish Versions 1.2 and 2.0 of the rulebook at the end of November 2026, following public consultations held between April and June 2026. The planned publications follow Version 1.1’s changes to operational guidance, API specifications and security requirements; their contents should not be assumed before publication.
For providers approaching the July 2027 deadline, the work involves more than displaying a match warning. They need a way to route requests, return results within the scheme’s time limit and present those results to payers before authorization. The rules also make the quality of the receiving provider’s validation consequential: a shared response format does not remove its responsibility for the data and matching decisions behind the answer.
Revolut’s expansion into UK consumer lending is facing closer regulatory scrutiny. The Financial Times reported on October 27, 2026, that the Bank of England’s Prudential Regulation Authority had ordered a Section 166 skilled-person review of the bank’s product approval processes and internal risk governance. The review comes as Revolut offers unsecured personal loans and prepares to introduce a domestic credit card, with mortgages planned later. Revolut UK CEO Francesca Carlesi has said the bank intends to package and sell loans through securitisation rather than retain substantial long-term credit exposure. Revolut is targeting a loan-to-deposit ratio of roughly 6%, far below the roughly 100% typical of incumbent British high-street banks. The strategy could support lending growth while limiting loans held on its balance sheet, but it does not eliminate credit risk. S&P Global has cited the possibility of higher credit losses as Revolut expands lending across multiple jurisdictions.
Sumitomo Mitsui Banking Corporation (SMBC) and Ant International signed a memorandum of understanding on October 26, 2026, to explore cross-border payments and digital treasury services. Their initial focus is Japan, Singapore and wider Southeast Asia. Engineering teams will examine whether Ant International’s Whale RTP platform can be integrated with SMBC’s institutional transaction banking and digital asset platforms. The agreement is exploratory, not the launch of a live settlement service. SMBC’s multi-market transaction banking rails are expected to support operations involving Ant International’s Alipay+, Antom and WorldFirst businesses. Ant International says its Whale platform processed more than US$600 billion in global treasury flows in 2025, with over 95% of transactions settling on the same day. Those figures describe the existing platform, not activity under the SMBC agreement. The MoU follows separate tokenized-deposit work involving Ant International and other banks, including a live OCBC solution and an HSBC pilot.
Tech Mahindra and Finastra announced on October 23, 2026, that Tech Mahindra had completed its acquisition of Finastra’s cash management products and related intellectual property. The deal moves Tech Mahindra beyond implementing banking software for clients and into owning transaction banking products. Financial terms were not disclosed. The acquired portfolio includes Fusion Cash Management, Fusion Virtual Accounts and Fusion Liquidity Management, along with CashPlus, Global CashPlus and associated transaction banking APIs. Finastra product engineering and customer success personnel are being moved into Tech Mahindra’s banking, financial services and insurance division. Tech Mahindra plans to integrate the products into its existing Finastra Centre of Excellence to maintain service continuity for banking clients. The acquisition follows Tech Mahindra’s earlier purchase of an 85% stake in Canadian fintech Avant Techno Solutions and comes as Finastra divests businesses to concentrate on lending and payments software.
The European Payments Council implemented Version 1.1 of its Verification of Payee scheme rulebook on September 20, 2026, clarifying operations, API specifications and security after feedback from live deployment. Its directory service, operated with SWIFT, has also completed a live transition supporting provider reachability and routing. The changes come as non-eurozone EU payment providers work toward a July 9, 2027, compliance deadline. Required under the EU Instant Payments Regulation for both instant and standard SEPA credit transfers, Verification of Payee checks recipient details before authorization and must be offered free to users. The inter-provider exchange has a five-second operational maximum and can return a match, close match, no match or verification-not-possible result. A close match supplies the verified recipient name for the payer to review. A warning does not necessarily prevent a transfer: liability depends on whether a payer proceeds despite it or a provider fails to perform a required check.
Fireblocks has rejected an Axios report that Visa was in advanced talks to acquire the digital-asset infrastructure company for about $2.5 billion. Fireblocks said the reported discussions were not taking place at present. Visa declined to comment on the claim, while Coinbase separately denied reports that it was considering a bid. None of the companies has confirmed an acquisition process. The reported price would be about 69% below Fireblocks’ $8 billion valuation from its January 2022 Series E funding round. The company generated $124 million in revenue in 2024 but remained unprofitable, and it has initiated plans to cut 60 to 70 jobs amid the rumors. Visa already uses Fireblocks as an institutional client and works with it on an interoperability initiative. Those existing links provide context for the speculation, but do not establish that a transaction is under discussion.
TerraPay and J.P. Morgan have connected TerraPay Verify with Kinexys Liink so participating financial institutions can check recipient details before sending cross-border payments to mobile money wallets or bank accounts. Announced on October 22, 2026, the integration allows Liink participants to configure bi-directional API queries with TerraPay Verify. It extends a validation network that already covers account details in more than 70 countries to wallet-related checks. The partnership targets a source of payment failures: a 2026 LexisNexis Risk Solutions study cited during the rollout attributed 10% to 15% of cross-border payment failures to incorrect recipient or beneficiary details. Wallet identifiers can differ from conventional bank-account formats, making early checks useful but not a guarantee that a payment will complete. The companies have not publicly disclosed commercial terms, query pricing or country-by-country rollout plans, and the available information does not establish how much the integration will reduce failures in practice.