Version 1.0 - Effective 2026-05-22 - Version history
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 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 LLC (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 Financial 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. Financial Institution 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.
Some of payware's Financial Institution counterparties act in a Lending Capacity: in addition to (or instead of) executing the payment, they finance the payer in respect of a Transaction by extending a loan, credit, or other financing (a "Funded Loan"), typically earning interest from the borrower. That lending activity is regulated for the lender - under the Consumer Credit Directive (Directive 2008/48/EC, recast as Directive (EU) 2023/2225 ("CCD2"), applicable from 20 November 2026) and the Bulgarian Consumer Credit Act ("ZPK"); and, for a lender granting credit from its own funds, by entry in the register of financial institutions maintained by the Bulgarian National Bank under Art. 3a of the Law on Credit Institutions ("ZKI").
payware carries on none of this activity. In a Funded Transaction:
Because payware neither grants credit nor intermediates credit, it is not a creditor, credit intermediary, or credit broker, and requires no authorisation, registration, or Art. 3a ZKI entry in respect of the lending activity of its Financial Institution counterparties. This characterisation is recorded in Sections 2.3(d) and 4.2(e) of the Financial Institution Partnership Terms, under which the Financial Institution warrants its own lending licence, authorisation, or registration and indemnifies payware against any claim that payware acted as a lender or credit intermediary. This position is contingent on the standing commitments in section 4 (in particular, that payware never lends and never receives interest or a credit-intermediation fee). Where a Financial Institution acting in its Lending Capacity settles the merchant payment out of loan proceeds, that settlement is executed either by the Financial Institution under its own authorisation (as a disbursement under a linked or tied credit arrangement) or by a separate regulated payment service provider the Financial Institution arranges; in either case payware neither executes nor procures that settlement, and relies solely on the Financial Institution's binding finality commitment (section 5).
Where a Merchant does not operate its own website, payware displays a link-only, non-search-indexed merchant directory listing to facilitate payment transactions. The listing content - including the Merchant's business description and its return, refund, and cancellation policy - is authored, controlled, and supplied by the Merchant; payware does not draft, verify, endorse, curate, rank, or exercise editorial control over any listing, and does not select which Merchants appear. payware acts as a neutral technical host of Merchant-authored content, consistent with the hosting-intermediary position under Article 14 of Directive 2000/31/EC (e-Commerce Directive) and Article 6 of Regulation (EU) 2022/2065 (Digital Services Act), and is not the seller or provider of the goods or services, nor the provider of the consumer information displayed. Accordingly, the directory feature does not make payware a consumer-facing intermediary, online marketplace, or trader, and does not confer on payware the consumer-protection or seller-disclosure obligations that rest with the Merchant, which remain solely the Merchant's responsibility under its Merchant Account Terms and applicable law.
To the extent the directory listing, combined with the Merchant's unique payment link, could be characterised as an "online intermediation service" within the meaning of Regulation (EU) 2019/1150 (the Platform-to-Business Regulation) in respect of business users offering goods or services to consumers, payware notes that: the directory is link-only and not search-indexed; payware applies no ranking within the meaning of Article 5 of that Regulation (there is no search function, ordering, or relative prominence among listings); listing content is Merchant-authored; changes to terms follow the notice mechanics of the Framework Agreement (Section D.5); and an internal complaint-handling channel is available to business users (Framework Agreement, Section D.2). This assessment is kept under review with counsel as the directory feature evolves.
payware undertakes, as a matter of architectural commitment and not merely operational practice, that it will at no time:
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 Financial Institutions that integrate with payware are the regulated entities in every Network transaction. payware partners with Financial Institutions that:
payware relies solely on that finality commitment and is not concerned with the manner in which the Financial Institution settles funds to the payee (section 3.6). payware does not contract with payment service providers whose role is limited to payment initiation or account information and that neither execute nor procure the fund movement.
Some counterparties additionally (or, in the case of a non-payment lender, instead) act in a Lending Capacity, financing the payer in respect of a Transaction (section 3.6). Such counterparties are separately licensed, authorised, or registered to lend - for example, by entry in the BNB register of financial institutions under Art. 3a ZKI, or by consumer-credit authorisation under ZPK / the Consumer Credit Directive. payware's role in respect of these counterparties remains purely technical: payware does not lend, fund, or intermediate credit, and the Financial Institution alone holds the credit relationship with the payer.
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 LLC
UIC 205863621
7 Vladimir Vasilev str., bl.16, ap.3
Sofia 1504, Bulgaria
Contact details as published on payware.eu.