Since 2016 I’ve been leading COREDO through dozens of licensing processes, hundreds of registrations and thousands of pages of contracts. The greatest value for clients is not the mere fact of obtaining a license, but a stable contractual framework that lays out the rules of the game: it is the payment system’s public offer that determines user trust, the reliability of settlements and the protection of funds. Europe is now moving to a new regulatory architecture: PSD3 and PSR, and the public offer is becoming a critical document that affects the business model no less than code and processing.
Update of the public offer for PSD3/PSR
PSD3 and the PSR (Payment Services Regulation) reallocate requirements between the directive and the regulation: some rules will become directly applicable, others will be harmonised through national competent authorities. This concerns client funds protection (safeguarding), strong customer authentication (SCA), open APIs for TPPs and operational resilience. The PSR public offer becomes the visible bearer of these requirements, and regulators view it not as a formality but as a reflection of risk management.
Public offer for PSP, EMI, e-money
I start the project by mapping risks and business processes. The solution developed at COREDO links each product feature to specific sections of the contract and internal policies. For EMI and e-money the offer must explicitly describe the funds protection regime, wallet types, limits and withdrawal operations, and the “e-money public offer and PSD3” must align with safeguarding accounts and insurance coverage.
Key blocks of the offer:
- user consent and acceptance mechanics (click-wrap, eIDAS electronic signature where high legal enforceability is needed);
- tariff transparency and the fee pricing model, including transaction margin and surcharges for cross-border payments;
- SLA metrics: authorization time, settlement time, service availability, incident priority;
- provisions on refunds and chargebacks, allocation of responsibility between PSP and merchant;
- public offer and protection of client funds: segregation, insurance, annual safeguarding audits;
- public offer and KYC/AML requirements: client’s obligations to provide data, blocking triggers, RBA;
- privacy: processing of personal data and GDPR, cross-border data transfers and localization requirements.
PSD3 Offer: PSR Requirements
- user rights and user protection in the PSD3 offer: clear information on risks, fees, limits, reimbursement rights;
- SCA and exemptions: biometrics, trusted beneficiaries, low-risk transactions;
- operational resilience and incident reporting: timeframes for notifying customers and the regulator, communication channels;
- third-party outsourcing: SLAs and supplier liability, right to audit, critical dependencies;
- independent audits, reviews and internal control: frequency, scope, remediation;
- capital requirements for PSPs and requirements for electronic money issuers (EMIs): methodology, stress tests, buffer maintenance.
PSR requirements also strengthen disclosures on payment routing, multilateral correspondent models and access-to-account obligations under open banking. This should be reflected formally and operationally.
PISP/AISP/marketplace/white-label PSP
For PISP and AISP the “public offer for PISP and AISP” must disclose third-party API access (TPP), the procedure for delegated consent, as well as the public offer in open banking conditions – who, when and how stores tokens, event logs and how to ensure users’ consent during API delegation. Our experience at COREDO has shown that unnecessary ambiguity here leads to complaints and loss of passporting.
For a payments marketplace, it is important to choose a model: custodian vs escrow. The public offer for a payments marketplace should explain segregation of sub-merchants’ funds, the settlement schedule and the terms for termination of service/transition of clients without the risk of funds “getting stuck”. In a white-label PSP we record the allocation of responsibilities between the licensed back-end provider and the brand, including Due Diligence when partnering with a PSP and the right to modernize the API without degrading the SLA.
AML/KYC and the risk-based approach in the offer
I set out risk-based approach (RBA): risk segments, CDD levels, triggers for enhanced due diligence, sanctions control and screening technologies. For transaction monitoring and SAR reporting, the offer establishes the right to suspend an operation, request documents, notify the FIU and national regulators.
Security and technical requirements for the text
Public offer and API security: mandatory section. I recommend formalizing requirements for OAuth2, JWT, key management and HSM, as well as the minimum compliance requirements in the public offer for PCI-DSS (network perimeter, PAN data encryption, card tokenization). At the protocol level it is worth mentioning the migration to ISO 20022 and its impact on consent schemes and the format of payment details.
Incidents should be described clearly: priorities, RTO/RPO, business continuity and disaster recovery in the offer, escalation procedures. For instant payments (TIPS, RTP, FastPay) we define specific SLAs and the risks of irrevocability, as well as mechanisms for post-authorization review and anti-fraud filters. The solution developed by COREDO combines these technical standards with legal obligations without conflicts.
User Consent and Notices
User consent: the foundation. In the offer I describe the mechanics of notification and obtaining users’ consent, including logs, IP addresses, timestamps, and, where necessary: eIDAS and electronic signatures in user agreements. For TPP processes I separately define how to secure users’ consent during API delegation, token validity periods and revocation.
A notice of changes to the offer terms must include the channels (e-mail, in-app), minimum timeframes, the client’s right to terminate the agreement without penalties before the changes take effect, and the rules for handling “silent consent” where permitted. Such a design prevents disputes and increases resilience to audits.
SLA and operational metrics in the offer
SLA is the language of trust for the merchant. We establish:
- authorization and confirmation times, the share of operations requiring re-authentication;
- settlement time (D+0/D+1), cut-off, deduplication;
- service availability (for example, 99.9%), maintenance window and the order of function degradation;
- dispute management and customer support in case of chargeback: TAT, channels, escalations.
For instant-pay services it is useful to include separate SLAs: the share of payments <10 seconds, average finalization time, and fallback routes in case individual schemes are unavailable. Agreements with merchants and settlement SLAs are reasonable to place in an appendix so that metrics can be updated promptly without changing the base text.
Safeguarding and capital in the offer
The public offer, safeguarding and segregation of client funds (safeguarding) are areas of close attention. Models for safeguarding: bank accounts vs insurance, their combinations and reconciliation timelines. I specify the frequency of reconciliation, the client’s right to information about custodial banks and independent auditor confirmations.
Cross-border operations, passporting, banks
In the offer we specify the geography of services, service currencies, country restrictions and the use of partner PSPs. Integration with correspondent banks and fees must be transparent: where correspondent banking fees may arise and who covers them.
The public offer for cross-border payments should take tax aspects into account: the public offer and taxation of payment services – who withholds taxes, how fees are treated for B2B and B2C. When operating in the EU, it is beneficial to reflect passporting and conditions for servicing non-residents; in Asia, the linkage to licenses by MAS, HKMA or DIFC/FSRA.
Disputes, refunds and chargebacks
Refund procedures and chargeback mechanics – not just links to a card scheme. I break it down step by step: timelines, required evidence, merchant’s role, allocation of PSP responsibility for infrastructure and routing errors. For A2A payments we set out separate error-resolution mechanisms, refunds at the initiative of the PISP and intervention by the account-holding bank.
Dispute resolution and an arbitration clause help avoid jurisdictional traps. Legal stipulations: applicable law and jurisdiction are chosen taking into account the license and domicile of safeguarded accounts. In the offer it is advisable to describe liability limits and indemnities: reasonable caps, exclusions for gross negligence and intent, and disclaimer in the public offer to the extent permitted by law.
Securing control in outsourcing
The public offer and the terms of subcontracting/outsourcing must specify that critical functions are transferred only to approved providers, with audit rights and security requirements. We specify third-party outsourcing: SLAs and provider liability, business continuity plans, compatible RTO/RPO. Clients must know that outsourcing does not diminish their rights, and the provider retains control.
For white-label and agency schemes and partnership models, we describe the separation between the storefront and the licensed entity, brand/license disclosure, passporting and the right to migrate to the ‘base’ provider upon termination.
Risks, TCO/ROI and compliance under PSD3
TCO and ROI assessment when adapting the offer for PSD3 is a mandatory management task. We calculate CAPEX/OPEX for API updates, legal reviews, resilience tests and independent audits. Potential fines and regulatory risks are correlated with incident probabilities and the impact on GMV and transaction margin.
Which offer terms increase merchants’ trust? Transparent SLAs, a clear responsibility matrix, flexible payment routing and clear chargeback rules. Which metrics should be tracked after updating the offer? CAC, LTV, GMV, share of successful authorizations, settlement speed, incident rate, merchants’ NPS, size of reserves and refunds.
PSD3 Roadmap: stages and timelines
- Gap analysis: differences from the current offer affecting PSR requirements, EBA recommendations.
- Structure redesign: PSP public offer template, linkage to SCA, AML/KYC, BCP/DR policies.
- Tech and risk review: API security, PCI-DSS, OAuth2/JWT/HSM, ISO 20022, instant payments.
- Legal components: applicable law, jurisdiction, limits and indemnities, outsourcing, safeguarding.
- Communication testing: consent mechanics, notice of changes to the offer terms, UX screenshots.
- Internal training: operational runbooks and KRIs, compliance project KPIs and execution control.
- Pilot and release: independent audits, establishing SLAs, metric monitoring, adjustments.
Timelines depend on scope, but on average we typically complete within 8–16 weeks if backend policies are ready and security is confirmed.
Implementation case studies in Europe and Asia
In the EU the COREDO team adapted the public offer for PSPs in Central Europe with the move to instant payments and the launch of marketplace scenarios. We defined an SLA for TIPS, set escrow reserves, and delineated responsibilities between the platform and sub-merchants. After the release, GMV grew due to the trust of large merchants, and the incident rate dropped by one third thanks to clear procedures.
Public Offer Template for PSP
Example of a public offer for PSP as a “skeleton” of sections:
- Terms and roles: PSP, merchant, user, TPP, PISP/AISP, marketplace and sub-merchants.
- Scope of services and geography: channel/schemes, instant payments, limited jurisdictions.
- Fees and commission model: transparent consumer information and disclosure, taxes.
- User consent and eIDAS: acceptance mechanism, delegation via API.
- SCA and risk management (PSD3): factors, exceptions, anti-fraud, KRI.
- Safeguarding: bank accounts vs insurance, reconciliation, audits.
- SLA for payment execution and settlement: metrics, service windows, degradation.
- Refunds and chargebacks: timelines, evidence, allocation of PSP liability.
- AML/KYC/CDD and sanctions: RBA, SAR, interaction with FIU.
- Privacy and GDPR: cross-border data transfer and localization requirements.
- Outsourcing and subcontracting: right to audit, security, reserves.
- Operational resilience: incident reporting, business continuity and disaster recovery.
- Payment routing and correspondents: fees, fallback channels.
- Restrictions and limits: transactions, currencies, merchant categories.
- Liability limits and indemnities, disclaimers in the public offer (within the law).
- Termination and transition: key termination and client transition points, data export.
- Applicable law, jurisdiction, dispute resolution and arbitration clause.
- Mechanism for notifying changes to the terms of the offer.
PSD3 Offer Verification Checklist
Checklist for PSD3 offer compliance:
- All roles, channels and schemes are specified, including PISP/AISP and open banking.
- SCA and exemptions are aligned with policies and UX flows.
- Safeguarding is transparent: banks/insurance, reconciliations, independent audits.
- SLAs are defined, KPIs are measurable, incidents are described.
- Refunds/chargebacks are detailed by scheme.
- AML/KYC/CDD RBA is clearly articulated, SAR and sanctions controls are reflected.
- GDPR and cross-border data transfers are validated by the DPO.
- Outsourcing: right to audit, API security, PCI-DSS.
- Legal provisions: limits, applicable law, spoliation-safe logging of consents.
- Notification and consent mechanisms are tested and logged.
- Integration of ISO 20022/instant-pay is reflected in terms and SLAs.
- National NCA requirements are considered, passporting is correctly described.
Assess ROI and reduce sanctions risks
Impact of PSD3: tokenization of crypto services
The impact of PSD3 on crypto services and tokenization is reflected in requirements for KYC/AML, SCA, storage and transfer of value through the payment infrastructure. A public offer and PCI-DSS requirements are important for card tokenization and on/off-ramp scenarios. For card tokenization and payment data security, we establish the merchant’s PCI obligations and the role of the tokenization provider, as well as cybersecurity obligations for APIs, OAuth2, JWT, and HSM.
API access for third parties and the terms of the offer must eliminate ambiguities regarding data rights and revocation of access. Open banking affects contractual relationships, and the offer must be aligned with the agreement with merchants and the SLA for settlements.
Regulatory practice and sandboxes
A regulatory sandbox for payment services in individual countries helps test a public offer for payment infrastructure with a limited set of customers. In our projects we often pilot the dispute resolution process, SLAs and safeguarding specifically in the sandbox to speed up subsequent certification.
The role of national competent authorities in supervising PSPs is strengthening, and the PSR public offer is the first point of contact for supervision with your «tone of compliance». The more precise the document, the easier it is to pass off-site and on-site inspections.
Practical wording: what merchants value
Which offer terms increase merchants’ trust? I clearly define responsibility for delays in settlements, a transparent discount matrix as turnover grows, and describe fallback routing of payments. Agreements with merchants often include KPIs for authorization, refund timeframes and support quality, as well as the right to early exit in case of SLA degradation. Such a balance of interests stabilizes GMV and reduces churn.
Work on COREDO projects
When a client prepares «public offer for a white-label PSP», we check the partner’s due diligence, its backup capacity, routing, as well as subcontracting terms. As a result the offer reflects the real risk landscape and withstands reviews by both EBA-guidelines and local NCAs.
The offer as a strategic asset
COREDO prepares «PSD3 payment provider offer» quickly and consistently, relying on audit practices and case studies across different jurisdictions. If your product needs «public offer for a PSP in the EU», «public offer when implementing instant payments» or «public offer template for PSP» for white-label and marketplace, the COREDO team will align the document with EBA requirements, the EU PSD3/PSR regulation draft and merchants’ expectations. I believe in a simple formula: a strong offer – fewer incidents, higher conversion, more sustainable growth.