This document explains payware's regulatory perimeter under EU and Bulgarian payments, e-money, operational resilience, and anti-money laundering law. It is published by payware EOOD for the information of partners, counterparties, regulators, and other interested parties. It is not legal advice. Where formal legal advice or a counterparty-reliance opinion is required, payware can arrange one with qualified payments counsel on request.
payware EOOD (UIC 205863621, Sofia, Bulgaria) operates a transaction information exchange network for account-to-account ("A2A") payment transactions. The network resolves a non-secret, non-personalised transaction reference into the underlying transaction data via secured business-to-business REST APIs. The licensed Payment Institutions ("PIs") that participate in the network execute the actual fund movement under their own regulatory authorisations.
payware is:
payware is not:
Funds never touch payware. payware operates no payment account, no safeguarding account, no omnibus account, and no settlement account. The customer's licensed Payment Institution executes the payment and performs Strong Customer Authentication ("SCA") under PSD2 Article 97.
This paper sets out the technical architecture and the regulatory analysis supporting these positions. Authoritative legislative and supervisory references are given in-line.
The network's defining technical primitive is the Transaction Reference: a 10-character alphanumeric string that is:
The Transaction Reference is the only data element exchanged at the point of interaction ("POI") between the payee's POI device and the payer's mobile device. Substantive transaction data - merchant identity, amount, currency, routing instructions - is exchanged exclusively via secured REST API between (i) the Merchant and payware, and (ii) payware and the customer's Payment Institution.
Seven Initiation Methods are available to convey the Transaction Reference from the POI to the customer's device:
| # | Method | Transmission medium |
|---|---|---|
| 1 | QR code | optical |
| 2 | Barcode | optical |
| 3 | NFC tag | contactless proximity |
| 4 | Bluetooth Low Energy ("BLE") beacon | contactless proximity |
| 5 | Hyperlink (deep link / URL) | digital |
| 6 | Text | digital |
| 7 | Audio "soundbite" | audio |
The choice of Initiation Method is a user-experience design decision. The legal and technical payload across all seven methods is identical (the Transaction Reference, and nothing else). The seven methods receive identical legal characterisation: the transmission medium does not affect the regulatory analysis.
At no point in this flow does payware:
Annex I of PSD2 and Article 4 of ZPUPS enumerate the eight payment services that require authorisation as a payment service provider. payware performs none of them.
| Annex I PSD2 service | payware position |
|---|---|
| 1-2. Cash placement / withdrawal | No cash, no payment account. Not within scope. |
| 3-4. Execution of payment transactions | No payment account, no fund movement. Execution is performed by the customer's PI. Not within scope. |
| 5. Issuing of payment instruments / acquiring | The Transaction Reference is not a "payment instrument" within Article 4(14) PSD2: it is non-personalised, issued per transaction not per user, and cannot itself initiate a payment order. payware does not contract with Merchants to accept and process payment transactions. Not within scope. |
| 6. Money remittance | No funds received. Not within scope. |
| 7. Payment initiation services (PIS) | payware does not initiate any payment order. The customer's PI calls payware's API on the PI's own initiative and constructs the payment order inside the PI's own banking application. The architecture is the directional inverse of PIS. Not within scope. |
| 8. Account information services (AIS) | payware does not access, retrieve, consolidate, or display any payment account information. Not within scope. |
The Court of Justice of the European Union confirmed in ABC Projektai (Case C-661/22, judgment of 22 February 2024) that the performance of a "payment service" requires the relevant party to receive and hold funds and effect a positive act of conversion. An actor outside the fund flow does not perform a payment service.
Article 3(j) PSD2 expressly excludes from the scope of the Directive:
"services provided by technical service providers, which support the provision of payment services, without them entering at any time into possession of the funds to be transferred, including processing and storage of data, trust and privacy protection services, data and entity authentication, information technology (IT) and communication network provision, provision and maintenance of terminals and devices used for payment services, with the exclusion of payment initiation services and account information services."
This exclusion is transposed in materially identical terms in Article 2(1), item 10 ZPUPS.
payware sits squarely within this exclusion: a business-to-business REST API supplying transaction-data resolution to Merchants and PIs, sitting outside the fund flow, outside the SCA flow, and outside any handling of payment instruments, payment account information, or payment orders. The European Banking Authority has confirmed in its supervisory practice that the Article 3(j) exclusion is to be read broadly, provided the entity does not enter into possession of the funds to be transferred (see EBA Opinion of 23 June 2022 on the review of PSD2, EBA/Op/2022/06).
The Transaction Reference is not a "personalised security credential" within Article 4(31) PSD2. The EBA Single Rulebook Q&A 2020_5476 (and the consequential Q&A 2021_6298) clarifies that customer-identifying data placed at the POI to support credit transfer initiation does not, by virtue of being so placed, become a "personalised security credential". The Transaction Reference is not even customer-identifying; it is a transaction-identifying lookup key carrying no SCA element.
The Council's final agreed text of the PSR, published on 23 April 2026 following political agreement reached on 27 November 2025, retains the technical service provider exclusion in Article 2(2)(i) and introduces an express definition of "technical service provider" in Article 3(36). payware is comfortably within this exclusion under the proposed framework.
The PSR will, when it enters into application (expected mid-to-late 2027 following Official Journal publication and a 21-month transition period reported in published practitioner commentary), impose certain direct conduct-of-business obligations on technical service providers and payment scheme operators - notably cooperation with SCA and a direct-liability regime where the technical service provider's failure causes financial damage to a payment service user. These are conduct obligations, not a licensing requirement, and they do not recharacterise payware as a payment service provider. payware monitors the PSR text and will adapt its operational practices and contractual stack accordingly during the application transition window.
"Electronic money" is defined in Article 2(2) EMD2 as "electronically, including magnetically, stored monetary value as represented by a claim on the issuer which is issued on receipt of funds for the purpose of making payment transactions [...] and which is accepted by a natural or legal person other than the electronic money issuer."
The CJEU in ABC Projektai (Case C-661/22) clarified that the issuance of electronic money requires both:
Neither limb is satisfied by payware:
payware does not issue electronic money, and is not an electronic money institution.
The proposed PSD3 repeals EMD2 and consolidates electronic money institutions as a sub-category of payment institutions. payware falls outside this consolidated regime for the same substantive reason: no funds, no monetary asset, no claim on payware.
A credit institution is defined in Article 4(1)(1) CRR as an undertaking the business of which consists of taking deposits or other repayable funds from the public and granting credits for its own account, or of carrying out specified investment activities at scale.
payware does not take deposits or other repayable funds from the public, does not grant credit, and does not carry out investment activities or underwriting. payware is not a credit institution and does not require authorisation under CRD / CRR / ZKI.
DORA applies directly across the EU/EEA from 17 January 2025. Its primary addressees are 20 categories of "financial entities" identified in Article 2(1) DORA.
payware is not a financial entity within Article 2(1) DORA. In respect of its services to its PI partners, payware is an ICT third-party service provider within Article 3(19) DORA. This status is not a licensing or authorisation requirement; it is the contractual-counterparty status that DORA contemplates for technology vendors to financial entities.
Article 30 DORA prescribes the contractual provisions that financial entities must include in their ICT third-party service agreements. Section 8B of the payware Payment Institution Partnership Terms implements the full Article 30 package, including:
Where a PI classifies payware's services as supporting a "critical or important function" within Article 3(22) DORA, the enhanced provisions marked "[CIF]" in Section 8B apply in addition to the baseline package.
Article 31 DORA empowers the European Supervisory Authorities ("ESAs"), acting through the Joint Committee, to designate certain ICT third-party service providers as "critical" and subject them to direct oversight. Designation requires cumulative satisfaction of the four criteria in Article 31(2), as further specified in Commission Delegated Regulation (EU) 2024/1502 (the "Criticality Delegated Regulation").
payware is not, and does not expect to become, a critical ICT third-party service provider, on two independent grounds:
Substitutability. payware is an additional payment initiation method at the POI, alongside cards, cash, and conventional bank transfers. Discontinuation of payware's services does not impair the PI's ability to execute payments, authenticate customers, settle funds, or maintain regulatory compliance through its own systems and channels. PI Partnership Terms Section 2.1(c) records this expressly.
Sub-threshold scale. The Criticality Delegated Regulation step-one quantitative thresholds (at least 10% of the relevant category of EU financial entities, at least 10% of total assets within that category, with at least 10% of customers facing "highly difficult" migration) are well above payware's current scale. The first ESA-published list of designated critical ICT third-party service providers, published by the Joint Committee of the EBA, ESMA and EIOPA on 18 November 2025 under Article 31(9) DORA, contains 19 entities - all large pan-European ICT, cloud, financial-messaging, financial-data and core-systems / consulting providers operating at systemic scale.
The catalogue of "obliged entities" under Article 3 AMLR, AMLD6, and Article 4 MAMLA is exhaustive. Each catalogue category requires either (i) the entity to itself perform a regulated financial activity, or (ii) the entity to be a designated non-financial business or profession.
payware fits neither limb. Specifically, payware is not a "payment service provider within the meaning of the LPSPS" (item 2 of Article 4 MAMLA / corresponding AMLR Article 3 category) because payware does not perform any payment service (section 3.1). payware is not an electronic money institution (section 3.2), not a credit institution (section 3.3), not an investment firm, not an insurance undertaking, not a crypto-asset service provider, not a crowdfunding provider, and not a designated non-financial business or profession.
Recital 21 AMLR confirms the underlying policy logic: intermediaries that do not handle "funds" within the meaning of Article 4(25) PSD2, and whose role is limited to a technical or supportive capacity, are not obliged entities.
This position is contingent on the standing factual condition (section 4 below) that payware never enters into possession of funds. payware maintains this condition as an architectural commitment.
The European Anti-Money Laundering Authority ("AMLA"), established under AMLAR and operational since 1 July 2025, does not have payware within its direct-supervision perimeter, given payware's regulatory classification.
payware undertakes, as a matter of architectural commitment and not merely operational practice, that it will at no time:
These commitments are reflected in the payware Payment Institution Partnership Terms at Schedule 1 and Section 2.2.
If payware were to alter its architecture so as to bring any of the above commitments into question, this Position paper would be reissued and the underlying regulatory analysis would be reassessed.
The Payment Institutions that integrate with payware are the regulated entities in every Network transaction. payware partners exclusively with PIs that:
payware does not contract with PSD2 service providers that cannot themselves execute the fund movement (such as standalone payment initiation or account information service providers).
Political agreement on PSD3 and PSR was reached by the European Parliament and the Council on 27 November 2025. Final compromise texts were published by the Council on 23 April 2026. Official Journal publication is anticipated in mid-2026, with PSR application following a transition period currently understood by published practitioner commentary to be 21 months (with a 24-month period applicable to the payee-name / unique-identifier verification obligation under the PSR).
payware's regulatory perimeter is expected to be unchanged under PSD3 / PSR:
The PSR will introduce direct conduct-of-business obligations on technical service providers and payment scheme operators, notably cooperation with SCA and a direct-liability regime where the technical service provider's failure causes financial damage. payware will adapt its operational practices and contractual stack as the Level 2 and Level 3 implementing measures crystallise.
PSD2 is a maximum-harmonisation directive in respect of the licensing perimeter and the categories of payment services (Article 107 PSD2). The exclusions in Article 3 PSD2 (and particularly Article 3(j)) are themselves part of the harmonised perimeter. Once the PSR enters into application, the conduct-of-business rules will apply directly as a regulation, eliminating residual national divergence in the licensing-perimeter analysis.
EMD2 is similarly harmonised. AMLR and AMLAR are regulations with direct effect, and AMLD6 (the residual directive) addresses national supervisory architecture rather than the obliged-entity perimeter. DORA is a regulation with direct effect.
payware's regulatory position is accordingly portable across the European Economic Area on a home-country / harmonised-law basis, subject to any residual national-implementation divergence in particular Member States in respect of Directive-based regimes. Where a counterparty requires host-state confirmation of payware's position in a specific Member State, payware can arrange this with local payments counsel on request.
The Network's commercial documentation is currency-agnostic, and the position set out in this paper is currency-neutral.
Cross-references to payware's published legal documents that are referenced in this Position paper:
This is a Position paper authored by payware. It is published for the information of partners, counterparties, regulators, and other interested parties. Authoritative legislative and supervisory references are cited throughout. It is not legal advice.
A formal legal opinion on the matters discussed here, suitable for counterparty reliance, can be arranged on request. Such an opinion would be issued by qualified Bulgarian and EEA payments counsel under their letterhead, and may be made available to specific counterparties on a reliance basis on terms to be agreed.
For questions about payware's regulatory perimeter, or to request a counterparty-reliance legal opinion:
payware EOOD
UIC 205863621
7 Vladimir Vasilev str., bl.16, ap.3
Sofia 1504, Bulgaria
Contact details as published on payware.eu.
Version 1.0 - 22 May 2026