A dedicated interfaces is an API that is suitable, secure, accessible, and dedicated to the function of allowing regulated third-party providers to access accounts and initiate payments on behalf of users. In other words, it's an API with layers of security and authentication which enable an account provider to verify a third-party provider and deliver the relevant mandated services. This is not to be confused with a standard API that an account provider may provide to its commercial clients or use for internal purposes. A dedicated interface plays a specific role in PSD2 open banking, and must be ring fenced for this purpose alone, and it must include a secondary layer of user consent lifecycle management. Alongside the APIs, a dedicated interface must also record and generate logs by endpoint including uptime, error rates and response times. Depending on the services available within an account providers product, a PSD2 dedicated interface must support (this is not an exhaustive list); account access (enabling a user to access their account information such as balance, transactions, beneficiaries etc) payment initiation (enabling a user to initiate a payment our of their account through a third-party provider) confirmation of funds

If you provide a payment account, either directly under your own license or in partnership with a regulated provider, then you do indeed need to have a dedicated interface. Article 4(12) of PSD2 describes a payment account as "an account held in the name of one or more payment service users which is used for the execution of payment transactions". The regs then go on to provide a series of examples of "payment transactions" "payment transactions executed through a payment card or a similar device" "execution of direct debits, including one-off direct debits" "execution of credit transfers, including standing orders" So if you operate a product - either directly or indirectly - which meets any of these criteria then yes, you do need to publish a dedicated interface.

It is the regulated entity that is responsible for ensuring that a dedicated interface is available, and that all regulatory requirements are met (including reporting). However, in most cases, that regulated provider passes the responsibility on to its client. There are many good reasons for this, including; It's often technically impossibly for a regulated provider to deliver this service since it require interaction with the user interface, which is typically controlled by the brand owner / programme manager A regulated entity will often outsource this responsibility to it's agent/client in the same way that it may do so with other requirements such as customer due diligence / SCA, user interface management, customer services etc. This is no different Many brand owners / programme managers have more than one "source of data", for example they may offer IBANs through one account provider and cards through another. As such, it is the brand owner that is ultimately the only one able to deliver a full dedicated interface experience As such, this responsibility is often delegated to the brand / product owner.

Absolutely! But it's complex and can be very expensive. If you are considering building your own dedicated interface, you will need to consider, amongst other issues, the following: A full review of the legislation (see below) to ensure that your solution is fully compliant How will you onboard third-party providers without creating any friction or delays, as the regulation require? How will you verify a third-party provider at the point of registration and in every API request, including validation of their live regulatory status? How will you log and generate regulatory reporting such as the UK FCA's REP020? How will you publish and maintain your API specification, including publishing of real-time usage and uptime statistics? How will you support enquiries and support requests from third-party providers? How will you demonstrate to your regulator or regulated provider that you have conducted thorough end-to-end tests using an authorised third-party provider, and that your solution is fully compliant? How will you keep on top of all regulatory changes, and implement them in a timely fashion? If you do choose to build your own dedicated interface, you may wish to start by looking at the following legislations: The Regulatory Technical Standards of PSD2 For specific requirements applicable to the interface, see section 2, articles 30-36 (page 15) . The FCA make the same information available via their website Article 32 relates to dedicated interfaces.

The regulations require account providers to publish daily statistics on a quarterly basis showing the availability and performance of their dedicated interface, and of each of the interfaces made available to its own end users for directly accessing their payment accounts online (e.g. customer servicing website or mobile app). In addition, the National Competent Authority (e.g. the FCA) require account providers to report these statistics to the FCA on a quarterly basis. In order to enable a 'like for like' comparison, guidance is available from the National Competent authority for the calculation of each element of data in regard to the interface availability and performance, covering: Uptime Downtime AISP Response Time PISP Response Time Confirmation of Funds Response Time Error Rate tell.money has created pre-configured 'dedicated interface' regulatory reporting. Dedicated interface availability and performance reporting can be immediately published on client websites via a simple link to the tell.money hosted developer portal; and reporting required for the National Competent Authority (e.g. FCA) is available 'real-time' via the tell.money Gateway management console.

If you choose tell.money as your open banking dedicated interface provider, we help you solve the reporting requirements. Clients with a Professional or Enterprise license receive automated quarterly reporting data for their dedicated interface, which can be submitted directly to their regulator or regulated provider. All that an account provider needs to do is to feed in information relating to their user interface (website / app), and the information is complete. This data is also automatically published in real-time on their developer portal. For clients using a Community (free) license, the same data is available via our Console - simply run the relevant report, extract the data, and format it as your regulator or regulated provider specifies.

Depending on its regulator or regulated provider, an account provider is likely to be required to produce some form of certification for their dedicated interface. If you are building your own or if you are using a supplier other than tell.money, you will probably need to self-certify. In order to do so, you can perhaps work with a regulated third-party provider and request them to develop some testing services for you. The third-party provider will need to perform end-to-end tests of all of your production endpoints, using live customer credentials, in order to validate that (a) everything operates as they would expect and (b) that the outcomes and methods are in accordance with local regulations. You will need to make arrangements with the third party in order to obtain some form of confirmation that can be shared with, and accepted by, your regulator or regulated provider. For tell.money clients with a Professional or Enterprise license, we will conduct this service for you as standard using our status as a regulated third party provider (FCA FRN 924109 - https://register.fca.org.uk/s/firm?id=0014G00002UwAOlQAN), at the end of which we will issue with a Certificate of Conformance.

Put simply, no. PSD2 does not have the notion of exemption when it comes to compliance with the requirements for open banking. An account provider with a product that is in scope must comply with the regulations and publish a suitable dedicated interface.

The PSD2 legislation does not allow for a risk-based approach. It is not the decision of an individual organisation to decide if it wishes to implement a requirement based on where or not, in its own judgement, it will be used. The rules are very clear. This is a firm requirement, and failure to adhere, regardless of reason, is a breach. Even if an account provider does not believe that its users will choose to access their account or initiate payments via a third-party provider, those users nonetheless have the right to do so. The beauty of open banking is the rich and constantly evolving landscape, and there are new and exciting services popping up all the time, many of which may be attractive to an account provider's users, even if that account provider doesn't know it yet. Unfortunately, this isn't an account provider's decision to make.

Whilst an account provider is within its rights to perform appropriate checks, unless there is a reasonable suspicion of fraud, there are no valid grounds on which an account provider can refuse to allow a third-party provider to connect. If a third-party provider presents the relevant certification which matches the PSD2 permissions for which they are requesting access, then they must not be stopped from doing so. An account provider also may not impose any fee for this service.

Failure to comply with the PSD2 can lead to hefty fines, greater regulatory scrutiny and in severe cases the potential for a reduction in services that can be made available to end users. Financial institutions should ensure that they are compliant with the regulations, and maintain a clear approach to maintaining compliance as the regulations evolve.