PSD3 is a Directive covering authorisation, licensing and supervision of payment institutions and electronic money institutions, applied through national law. The PSR is a Regulation that applies directly in every EU country and contains the open banking conduct rules: API performance, permission dashboards, fraud rules and strong customer authentication.

PSD2 was a single directive that each country wrote into its own national law, which produced different rules in different markets. The new package separates the two functions into two texts.

When people refer to "PSD3 API requirements", the obligations they mean sit in the PSR.

Salt Edge delivers the PSR conduct layer for banks, EMIs and payment institutions.

They are not in force yet. Political agreement was reached in November 2025 and the final texts were published in April 2026. Official Journal publication is expected in the second half of 2026. Most PSR rules apply about twenty-one months after that, which points to 2028.

Until then, PSD2 and the SCA technical standards remain the law in force.

The build window for an account-servicing provider is 2026 and 2027, because the interface work has to be complete before the rules apply.

Salt Edge implements each standard release as part of the platform licence.

FiDA, the Financial Data Access Regulation, extends data sharing beyond payment accounts to mortgages, consumer credit, savings, investments, pensions and some insurance. It is still in trilogue negotiation and has not yet been adopted. Current expectations point to phased application toward 2029 and 2030.

FiDA introduces financial data sharing schemes that institutions join in order to share data lawfully, and a new provider type, the FISP, which uses customer data with permission.

The scope and the data holder compensation mechanism are still being finalised. The interface decisions taken for the PSR determine what FiDA costs later.

Salt Edge covers PSR compliance and FiDA readiness on one platform.

The PSR makes the dedicated API the main access route and sets three duties. The API must perform at least as well as the interface the bank offers its own customers. Customers must get a permission dashboard to withdraw third-party access in real time. The standing fallback interface is replaced by a supervised contingency mechanism.

Performance is measured against indicators the EBA will set in technical standards, which are not yet published.

This means the obligation is not fixed at a single point. It continues as each technical standard is issued.

Salt Edge implements each standards release as part of the platform licence, so the obligation does not become an internal project.

No. The standing fallback interface and its exemption regime, which many banks built and maintain under PSD2, are replaced by a contingency mechanism supervised by the competent authority.

This is one of the clearest architectural changes in the package. A bank that built and now maintains a fallback interface should plan for that component to be retired.

The contingency arrangement is a supervisory process, not a second permanent interface.

Salt Edge handles the contingency mechanism as part of the compliance layer.

It applies to all account-servicing payment service providers that hold payment accounts, which includes banks, electronic money institutions and payment institutions. Smaller institutions are not exempt from the API duties. Either the accounts are proven out of scope, or the institution complies in full.

A basic gateway or an unmaintained API placeholder does not meet the PSR interface duties.

Salt Edge serves banks, EMIs and payment institutions on the same platform, and delivers the compliance layer for smaller institutions in weeks.

Institutions have three options: build the interface in-house, join a national or sector consortium, or use a specialist compliance vendor. Among specialist vendors, Salt Edge provides an ASPSP compliance and open finance platform covering PSD2, the PSR conduct rules, FiDA readiness on Berlin Group openFinance, and premium APIs.

The right option depends on how the institution solved PSD2, which is the starting point of any evaluation.

Salt Edge is used by banks, EMIs and payment institutions across the EU and EEA, including Landsbankinn, Bank of Valletta, LHV, Guaranty Trust Bank and Jordan Ahli Bank.

Both are valid. An in-house build must cover four things continuously: standards implementation, regulatory monitoring, third-party operations, and interface reliability at PSR performance levels. Each is a recurring cost rather than a one-time project. The question is where engineering and compliance capacity is best spent.

Many institutions that built for PSD2 conclude that a second build for the PSR and FiDA is not the best use of that capacity.

A workshop with Salt Edge produces a written recommendation on the options, based on the existing architecture.

Ask the consortium two questions: will it deliver FiDA, and will it offer premium APIs. Many answer “no” to at least one. A consortium usually covers the regulated baseline, but its roadmap moves at the scheme's pace, and premium APIs are generally outside its scope.

The consequence is that full FiDA scheme participation may arrive later than an individual bank wants, and commercial flexibility is limited.

Salt Edge adds FiDA readiness and premium APIs on top of what the consortium already delivers.

A migration reuses the existing integration layer rather than rebuilding it, so the effort is lower than most teams expect. The variables that matter are the complexity of the core banking connection and the target scope: the PSR only, or the PSR plus FiDA plus premium APIs.

Salt Edge connects to an existing gateway or middleware and delivers compliance out of the box, so the switch is scoped as an integration rather than a programme.

Cost depends on the starting point, the complexity of connecting to core systems, and the target scope: the PSR only, or the PSR plus FiDA plus premium APIs. The costs most often underestimated are recurring: standards releases, third-party operations, NCA reporting, and maintaining interface performance year after year.

A single published figure without the institution's own assumptions does not produce a business case.

In a workshop under NDA, the Salt Edge enterprise team works through the architecture and produces a written recommendation on migration options and an implementation roadmap.

The regulated baseline must be provided without charge. Services beyond that baseline are commercial and can be priced. That distinction is what makes premium APIs possible: the interface built for compliance is the same interface through which commercial services are sold.

Premium services are sold to commercial partners, corporates and embedded finance platforms.

Salt Edge delivers the regulated layer and the premium layer on one platform.

Premium APIs are services beyond the regulated baseline, offered commercially. They include premium account information and payment initiation, variable recurring payments, sweeping, Request to Pay, account notifications, corporate payment services in single and bulk form, ERP integration and multi-banking.

Revenue is earned by pricing these services for commercial partners, corporates and embedded finance platforms, using the same interface built for compliance.

Salt Edge provides these APIs pre-integrated, so the compliance interface also generates revenue.

For institutions already on the Salt Edge platform for PSD2, the PSR conduct requirements are delivered as part of the platform. For a new institution, the timeline is measured in weeks, against the six to eighteen months an in-house build typically takes.

The compliance layer is off the shelf. Only the connection to the institution's systems is specific to each project.