Changelog
The policy is in force
From 2026-08-04 this specification is stable and every breaking change gets three months’ notice. Before that date it was a moving target and said so: nothing had served a provider, so no correct integration existed that a change could break, and corrections shipped without notice. That period is over. You may pin against this version.
Our change policy
Breaking changes to this interface are published at least three months before they take effect (RTS 2018/389 Art. 30(4)). A breaking change means anything that could make a correct integration stop working: a removed endpoint, a removed or renamed field, a narrower accepted input, a new required header, or a change to the Berlin Group specification version we implement.
Non-breaking additions — a new optional field, a new endpoint, clarified prose — ship without notice and are recorded here.
The exception is a security fix, which may ship immediately. When that happens we document it here afterwards and explain why the notice period was not observed.
Corrections — the case the policy above does not obviously cover
Sometimes the interface does not do what these documents say, and we fix the interface. That is a correction, and it is worth being explicit about how we treat it, because you may have integrated against the behaviour rather than the document.
A correction ships without notice. We are not going to leave a documented contract unmet for three months. If your integration follows the published documents, a correction can only move us toward you — the case it breaks is a client that adapted to a bug.
But every correction is recorded here, on the day it ships, and named plainly enough that you can tell whether you had worked around it. That is the half that matters to you, and it is not optional: the value of this page is that you can learn from it that behaviour you built against has moved.
Why this is stated at all: a provider building against our sandbox hit
PRODUCT_INVALID where the catalogue promised PAYMENT_FAILED, and a less
careful integrator would have changed their client to expect the wrong code and
then broken silently when we fixed ours. They asked us which way the policy cut.
This is the answer, published rather than left to be inferred.
So: build against the documents. Where the interface and these pages disagree, the pages are what we are obliged to deliver, and the difference is a bug you should tell us about rather than accommodate.
Subscribe to changes via support.
Releases
2026-08-04 — production open
https://xs2a.paysaxas.com answers. AIS, PIS and CBPII are all live, at the
version of this specification published on this date; the sandbox at
https://xs2a.paysaxas.money stays open unchanged and remains the place to
test.
Registration is self-service and there is nothing to apply for: present an eIDAS QWAC carrying your PSD2 QcStatement and your first call registers you, with your roles read from the certificate and checked against the EBA register.
One known limitation. Certificates issued by the Cypriot QTSP are not yet
trusted and are refused with CERTIFICATE_INVALID. This is our trust store,
not your certificate. If it affects you, contact support — the
fix is a rebuild of the store on our side and needs no change from you. It will
be recorded here when it lands.
From today the change policy above binds: breaking changes are announced here at least three months before they take effect.