top of page

The problem

The primary objective of EU financial regulation is and has for a long time been to maintain confidence in the financial system. To contribute to the resilience and stability of the financial system while at the same time ensuring an appropriate level of protection for consumers. As the global digital transformation kept challenging the way the financial industry worked, the EU defined a whole new framework to better conform with the nature of the evolving European financial market. One of the instruments in this framework is the 2nd Payment Service Directive (PSD2).

The PSD2 requires banks (ASPSPs) to provide dedicated interfaces for regulated third parties (TPPs) with functionality and quality equal to what is provided in the banks own channels. As this is a regulatory requirement, the normal partner relation between the bank and TPPs is somewhat challenging relationwise because of the competing atmosphere between the TPP and the bank.

​Fintechs (TTPs) throughout Europe are eagerly awaiting action from regulators and are documenting potentially noncompliant aspects of these interfaces in numerous ways, and reporting this to regulators and media.

Banks have limited tools for responding to such reports, both in terms of building functionality that is found to be lacking, as well as providing effective responses to observations they believe to be incorrect.

​Regulators on their side would benefit from better and more standardized documentation of perceived or actual noncompliance from both ASPSPs and TTPs alike, enabling them to focus regulatory priorities and operate more efficiently.

​ is bridging this gap by providing simple and efficient tools for reporting observations without direct agreements between the parties. This will reduce the risk that the PSD2 fails to achieve its purpose and deliver the intended benefits to society.

RTS Article 33

The PSD2 regulation contains a set of underlying legal instruments. One significant such is Delegated Regulation 2018/389, The Regulatory Technical Standard (RTS). One of the articles in the RTS (Article 33) requires contingency measures - including reporting obligations - for ASPSPs and TTPs. is designed to assist compliance with Article 33 by various tools. For example streamlining non-conformity notices from TPPs, enabling responsive actions from ASPSPs in case of breaches to prevent escalation as well as offering regulated entities and regulators alike increased insight through data.

What does

The service enables TPPs to report observations of potential noncompliance in dedicated interfaces through “tickets”. Subscribing ASPSPs are given an opportunity to process tickets and resolve potential problems within a 72-hour window.

Industry associations engaged in the initiative are able to create community tickets to address problems with wider relevance, and all the above can utilize the service as a basis to provide standardized reports to regulators.

​ is designed to work with open datasets uninhibited by copyright restrictions.

What services do offer offers five types of service subscriptions.

Two freemium services enabling TPPs and banks acting as TPPs to issue tickets and browse the published tickets.

Two premium services provide more efficient and collaborative management and access to export of Ledger data content in various formats.

The fifth offer is an industry association service subscription providing the ability to facilitate escalation of disputes relevant for multiple association members. The subscription also allows the association to gather relevant data analytics to enhance reports used for authorities and stakeholders relevant for the industry association.  


Is initiative financially viable?

The objective of the initiative is to offer an efficient and neutral way of communication and data collection for the benefit of all market players.

The 33 initiative is, on a policy level, managed by a Governance Board. One task of the Governance Board is to define value added services that can increase revenue to fund development of a better service, while retaining operational resilience.

​Given the fact that the initiative does not have any commercial objective except for the participants; and is not funded by either VC, PE or any governmental institutions, participant funding is therefore key, both for the resilience and independence of the initiative.

​Regarding innovation and further development, efforts taken in targeting more hurdles in the scope of regulated collaboration between TPPs and ASPSPs may also be financed by donations and/or project funding.

How works is providing a web-based tool for TTPs to document and share descriptions about PSD2 related concerns with dedicated interfaces provided by ASPSPs. The content of an observation is referred to as a ticket. The processing of a ticket is designed to be a facilitated collaborative dialogue between the TPP and the relevant ASPSPs, not visible to other participating entities in the initiative until the ticket is finalized and published in the Ledger.

The platform also provides a tool for industry groups to aggregate or highlight concerns based on tickets mentioned above. Those collective views of the specific concern are gathered into what we call a community ticket og community positions. Community tickets relating to a specific ASPSP will be processed in the same manner as a ticket, but the author is in this case the designated industry group.

​When a ticket registration is completed from a TPP, it will be sent to the ASPSP which will have 72 hours (gracetime)  to respond. The participating ASPSP may respond with an acknowledgment of the concern and/or other information to help the TPP in the decision of the final status attached to the published version of the ticket.

If the participating ASPSP does not contribute within the gracetime limit, the response will be automatically released to the originator with the status of "no comment". If the ASPSP is not connected to the platform the ticket will automatically be published in the Ledger.

​Tickets published in the Ledger are available for all participants in the initiative. 

Who decides the rules and/or governance of

Once the initiative reaches a preset threshold of participants, a  Governance Board will be set up.  

This will be run by a  third party and consist of both ASPSPs, TPPs and externals - to provide guidance and governance for developing the initiative.

Until such time, the governance of the initiative is defined by the participants who are actively connected to

Who is participating in

We do not list participating fintechs, banks or the content they provide through

Upon the explicit request from participants, we may publish logos and general public information for marketing purposes on this website or social media. Banks may choose to publicize their participation by publishing reportforms or promote the use of the service when issuing notices for the specific bank.

As for the industry associations we will provide a publicly available list of participating Industry associations holding a position as market relevant industry representatives and co-chair at the governance board.  

No government entities are allowed as users of the service, but they may be recipients of content shared by the users. 

Security and compliance


The platform is developed according to best practices based on the ISO 27001 standard. The initiative is still in a start-up phase, and several organizational elements need to be designed and operationalized for any certification process to be appropriate, but there is a long-term goal of achieving this.

Information security

The solution consists of two parts.  The first, the processing stage, provides a tool for facilitating dispute resolution in a bilateral setting.  The second takes a set of data from this first phase and makes it available to the community at large as open data. Even with the open data approach at the core, confidentiality requirements are still relevant for the processing stages of ticket issuance.  This need is being met by role-based access management, controlling access to both data and functionality. 

The platform also mitigates the confidentiality risk by separating the infrastructures for the Ticket Engie and the infrastructure providing the Ledger.  This separation is also important for achieving the stated policy of having no personal data in the Ledger.

Availability requirements of the platform are considered a business requirement and mitigated by use of reliable cloud service providers with proven technologies and easily accessible methods for exporting data for users to further analyze locally. 

The integrity of our data is our most important security goal, since the value proposition is to gather relevant data to be used in processes and evaluations by both banks, regulated third parties, industry associations and regulators. 

The impact of an integrity breach could be damaging to all parties. We are constantly improving our mitigating actions to ensure the quality of the data is adequate for the purpose the participants are using it for.

How to contact

You can contact us using this form

33report supporting documentation

The Specification, Policies, Subscription- and  End User License Agreements are available on our Download page.

bottom of page