# Regulatory checking

# Overview

For a PSP to operate they must register with the NCA of the country they are based in. For example, a PSP based in the UK would register with the Financial Conduct Authority (FCA). When a PSP applies to their home NCA the home NCA will undertake a number of checks to ensure they are eligible to operate and what payment services they can provide within the NCA's jurisdiction.

If a PSP wishes they can also request to operate outside their home Member State using the right to passport their services or establish a branch. To conduct payment services outside their home Member State a PSP must notify its home NCA of its intentions and the home NCA will apply to another EEA Member State in order for the host NCA to undertake checks on the PSP to ensure they are eligible to operate.

This page covers the register categories found on the NCA registers and EBA register, the 8 payment services a PSP can provide, the passporting process and how Konsentus's regulatory checking service tests a PSPs status. For response examples please go to GET /v1/psp/eidas.

# Register categories

An NCA register or the EBA register is made up of a number of different PSPs. PSD2 sets out seven categories of PSP that are authorised to provide payment services, below is a summary of each category:

# Payment Institution

Payment institutions are allowed to provide payment services (such as credit transfers, direct debits, electronic credit card transactions, money transfer). Payment Institutions differ from credit institutions and e-money institutions as they are not allowed to hold a Payment Service User's (PSU) money unless they have a payment instruction (the details required to make a payment to an account).

# Exempt Payment Institution

An exempt payment institution can operate in a similar manner to a payment institution but are defined by the EU as a payment institution that has processed less than €3 million payment transactions in the past twelve-month period (this can be set at a lower level by an NCA if they wish).

As such they are not required to undergo the same checks a payment institution must take when registering. Consequently, exempt payment institutions contain a "registered" status as opposed to an "authorised" status to reflect a lower level of regulation.

# E-Money Institution

E-money institutions can be defined as institutions that issue electronic money. This means that they can hold a PSU's money (that is a PSU stores money with the institution, but the institution cannot lend or invest the money) and make that money available for withdrawals or payments.

# Exempt E-Money Institution

An exempt e-money institution can operate in a similar manner to an e-money institution but are defined by the EU as an e-money institution whose business activities generate less than €5 million of electronic money (this can be set at a lower level by an NCA if they wish).

As such they are not required to undergo the same checks an e-money institution must take when registering. Consequently, exempt e-money institutions contain the "registered" status as opposed to an "authorised" status to reflect a lower level of regulation.

# AISP

An Account Information Service Provider (AISP) is an institution who is only authorised to perform the eighth payment service. They may be in their own category in an NCAs register and contain the authorisation status of "registered" as opposed to "authorised" to reflect a lower level of regulation.

# Credit Institution

A Credit Institution can be defined as an institution that allows a PSU to deposit money with them (that is they can lend or invest the money that PSUs put into their accounts). Consequently, PSD2 recognises that any Credit Institution in an NCA register is entitled to perform all eight of the PSD2 payment services.

# Payment services

The PSD2 directive states that there are eight payment services that a PSP can provide. Each register should display a PSPs authorised payment services, below is the list of the eight payment services:

Services enabling cash to be placed on a payment account as well as all the operations required for operating a payment account
Services enabling cash withdrawals from a payment account as well as all the operations required for operating a payment account
Execution of payment transactions, including transfers of funds on a payment account with the user's payment service provider or with another payment service provider

a) execution of direct debits, including one-off direct debits

b) execution of payment transactions through a payment card or a similar device

c) execution of credit transfers, including standing orders
Execution of payment transactions where the funds are covered by a credit line for a payment service user

a) execution of direct debits, including one-off direct debits

b) execution of payment transactions through a payment card or a similar device

c) execution of credit transfers, including standing orders
Issuing of payment instruments and/or acquiring of payment transactions
Money remittance
Payment initiation services
Account information services

It is easy to confuse the above payment services with the roles that are found on eIDAS certificates. The roles in eIDAS certificates are based on the above payment services as a QTSP will need to check the appropriate NCA register before they can write roles into a certificate. As such you can map the following eIDAS roles to the following PSD2 roles:

eIDAS Role	PSD2 Payment Service	PSD2 Payment Service Description
PSP_PI	7	Payment Initiation Services
PSP_AI	8	Account Information Services
PSP_CBPII	5	Issuing of payment instruments and/or acquiring of payment transactions
PSP_AS	1 to 8	Account Services

It is worth noting that although there is a degree of reliability with the roles written into an eIDAS certificate (as the QTSP would have been required to check an NCA register) they are not as reliable as the NCA registers themselves. As such, when Konsentus performs a regulatory check it will return the payment services that it finds on the NCA register(s) and not the roles on an eIDAS certificate. This means that the regulatory check returns the payment services in the PSD2 format (1 - 8 index number) and not the eIDAS certificate role format (PSP_AI, PSP_PI, etc).

# Passporting

After a PSP has successfully obtained authorisation from their Home NCA they have the opportunity to provide payment services throughout the EEA using the passporting service. In order to provide payment services to other EEA countries a PSP must apply through their Home NCA to passport to another EEA country (Host NCA). It is the responsibility of the Home NCA to pass these details onto the Host NCA who will have the opportunity to object to the request for a PSP to passport their services into their country. Assuming no objection was raised it is the responsibility of the Home NCA to update their register to show that a PSP is authorised to passport its payment services to a Host member state. The process is known as passporting-out.

When checking a certificate the passportOut field is not provided for the following reasons:

When the requested jurisdiction field matches the home country of the PSP
When the PSP is not authorised to passport to the jurisdiction provided
When the NCA itself doesnt provide passporting information for its registered PSPs

It is possible that a Host NCA will also update their register to show a PSP who has passported their payment services into the Host member state. This action by the Host NCA is optional and is not a legislative requirement. This process is known as passporting-in.

As it is optional for a Host NCA to add passported-in PSPs to their register this raises the possibility of a number of data quality issues. An example includes missing and inconsistent passporting-in data. In addition, a number of Host NCAs state they hold no obligation for the quality of the passported-in data. It is important that we protect our clients from a false positive response in the event of inaccurate Host NCA data. To do this we have set our 'host register' check to show "The PSP could not be found in the register". Until Host NCAs are required to ensure the accuracy of their passporting-in data clients should look for a response in our passportOut (Home NCA) check only. Please note, the only exception to this is GB’s Temporary Permission Regime which uses passporting in data and clients should look for a response in our hostRegister check. For further information, please see 'GB-FCA Temporary Permission Regime' below.

There is a limited amount of NCA data available regarding credit institutions and their ability to passport out their services. This has resulted in a consultation being issued by the European Banking Authority (EBA), aimed at improving the data quality and completeness for credit institutions and their passported activities. We will only provide accurate data from the relevant NCA. Consequently, where data is unavailable for credit institution we will only show "The PSP could not be found in the register" until the results of the consultation are realised and the NCA data quality has improved.

# Jurisdiction logic

The Konsentus jurisdiction field provides ASPSPs with the option to select the country where the PSU transaction is taking place. Below is a description of the three most common scenarios:

# Scenario 1

If a PSP and ASPSP are both in Great Britain, then the ASPSP puts jurisdiction GB in the Konsentus Verify API call. The PSP is registered by its Home NCA (FCA- Great Britain). The Konsentus service checks the PSP on its Home NCA (FCA- Great Britain) and returns payment service for Great Britain, to the ASPSP.

# Scenario 2

If the PSP is in Great Britain and the ASPSP is in Germany, then the ASPSP puts jurisdiction DE in the Konsentus Verify API call. The PSP is registered by its Home NCA (FCA- Great Britain). The Konsentus service checks the PSP on its Home NCA (FCA- Great Britain) and looks to see if they have passported their services to Germany. If NO, then the Konsentus service returns payment services for Great Britain and reports that the PSP has not passported its services to Germany. If YES, then the Konsentus service returns payment services for Great Britain and reports the PSP payment services to Germany.

# Scenario 3

If the PSP is in Great Britain, the ASPSP is in Germany and the client calling the Konsentus service is in France but managing accounts for PSUs in Germany then the client puts DE in the Konsentus Verify API call. The PSP is registered by its Home NCA (FCA- Great Britain). The Konsentus service checks the PSP on its Home NCA (FCA- Great Britain) and looks to see if they have passported their services to country Germany. If NO, then the Konsentus service returns payment services for Great Britain and reports that the PSP has not passported its services to Germany. If YES, then the Konsentus service returns payment services for Great Britain and reports the PSP payment services to Germany.

For response examples please go to GET /v1/psp/eidas.

# GB-FCA Supervised Run-Off

The FCA released an update which confirmed that the TPR scheme will end on the 31st of December 2023. For further information see Considerations for firms leaving the TPR (opens new window)

This will impact credit institutions and PSPs who operate in the GB without FCA authorisation, as they will no longer be able to rely upon the TPR scheme to "passport" their services into the GB.

# What is the Temporary Permissions Regime (TPR)?

The TPR is a list of pre-registered PSPs who have an agreement with the FCA to provide payment services into GB.

The TPR list is owned and managed by the FCA. Unlike the traditional passporting rules the FCA is responsible for passporting into their jurisdiction, rather than the home NCA being responsible for their PSP passporting to the GB jurisdiction.

# What is the Supervised Run-Off (SRO)?

It enables EEA-based firms that previously passported into the GB and that did not enter the TPR to wind down their GB business in an orderly fashion

The FSCR provides two mechanisms; the Contractual Run-Off (CRO) for remaining incoming cross-border services firms, and the Supervised Run-Off (SRO) for those EEA firms with GB branches or top-up permissions in the GB, and firms who entered the TPR but then did not secure a GB authorisation;

Firms that have entered into SRO must notify the FCA for inclusion on the SRO list. A firm can remain on the SRO scheme for;

a maximum of 15 years for insurance contracts, or
a maximum of 5 years for all other contracts

# What Do You Need To Do?

You can continue to use the passportIn data range for SRO and branches operating in GB.

If a PSP is removed from the TPR, the hostRegister will show the PSP status as unauthorised. However if the PSP joins the Supervised Run-Off, they will continue to appear as authorised.

It is expected that PSPs who wish to maintain long-term activities in GB will establish a new subsidiary within Great Britain. The new entity would therefore have a new registration number and require new certificates. These new subsidiaries would then appear in the homeRegister data range, with no relationship to its previous record.

For UK registered ASPSPs, Konsentus Verify will check that an EEA PSP is permitted to operate in the UK under the Supervised Run-Off. This permission will be provided in the passportIn field in the hostRegister object in the API response.

An example of this response is shown in our user documentation at Scenario 2: Host register check.

UK ASPSPs, using the GB jurisdiction, must check the authorisation data provided in the passportIn field to determine if they should grant the PSP access.

# Checking for permission under the Supervised Run-Off

Below is an example of how to check if a PSP is authorised to access a UK ASPSP.

If an ASPSP's jurisdiction is GB and a PSP's jurisdiction is an EU country (not GB), the PSP is only authorised to access the UK ASPSP's accounts if the following is true:

PSP is not UK registered

"homeRegister": {
   "ncaCountryCode": // is not 'GB'
}

AND

Submitted payment services from the PSP matched the role under the Home Register:

"homeRegister": {
   "categoryEntries":
      [
         {
            "pspAuthStatus": "Authorised", // OR 'Registered'
            "pspPaymentServices": // must match PSP payment services submitted
         }
      ]
}

AND

The PSP is on the FCA's Temporary Permissions Regime register which is returned in the hostRegister data object:

"hostRegister": {
   "passportIn":  {
      "countryCode": "FR", // must be present
      "paymentServices":  // must match PSP payment services submitted
   }
}

There is no impact on the way Konsentus Verify is called, only the way the returned data is interpreted.

# Konsentus regulatory checking service

When an ASPSP uses the GET /v1/psp/eidas endpoint Konsentus will run the following regulatory checks on the PSP:

PSP's home register details (NCA name, country code, register type)
PSP's category within their home NCA register
PSP's authorisation status within their home NCA register
Payment services that the PSP is authorised to provide from their home NCA register
PSP's authorisation status from the home NCA register for services provided to a host country (host country is to be defined using the jurisdiction input)
Payment services that the PSP is authorised to provide within the home NCA register for services provided to a host country (host country is to be defined using the jurisdiction input)
PSP's authorisation status within the host NCA register (host register is to be defined using the jurisdiction input)
Payment services that the PSP is authorised to provide from the host NCA register (host register is to be defined using the jurisdiction input)

← eIDAS GET /v1/psp/eidas →