The following questions and answers have been published in categories to make it easier to find the relevant topics. Please use the search functionality in your browser to search for specific words.
If you are new to the PSD2 API you are advised to read all of the topics below to get a better understanding of the implementation. Please also see the general documentation. 

Please also read the full API specification as the FAQ does not describe the implementation from A-Z.

Payment Initiation Services (PIS)

The PIS API implements the Payment Initiation Service parts of the PSD2 specification, and provides the following services to authorized TPPs; Initiation and update of a payment request, status information of a payment.
The PIS API exposes the general payment products and payment types which are also available for the PSU through the self-service channels of the ASPSP.
 

Payment Initiation
The Payment Initiation initializes payment(s) of a specific payment product and payment type.

Q: Do you follow a specific standard for BBAN?
A: All BBANs will be 14 digits following the general standards

Q: Can the TPP delete a payment without interfering with the PSU?
A: If the PSU has approved the payment via SCA, the PSU must also approve the deletion of a payment.
If TPP creates a payment initiation, this can be deleted by TPP without PSU involvement - but only as long as PSU has not approved or partly approved the payment via SCA.

Q: For how long time can the TPP request status and get details of a payment initiation?
A: There are no direct restrictions on how long time it is possible to request status and get details of a payment initiation. The objects will be removed after a period of time following the deletion rules defined by the ASPSP.

Q: How does Payment Initiation work on non-banking days?

A: The PSD2 solution is built in a way that the bank (ASPSP) does not change the input from the TPP, as BEC has no knowledge if an automatic change can interfere with the business of the TPP. It is up to the TPP to make sure to handle this. If the user tries to select a non-banking day in the self-service channels the user will be prompted to select a proper date. This is how it is implemented in the PSD2 API also.

Payment Authorization
The payment authorization is the process of a PSU authorizing the payment initiation done by the TPP. The Authorization is done using the Danish domestic solutions; NemID or MitID.

Q: The payment authorization went wrong for some reason. Can you investigate why?
A: Potential error messages will be provided in the psuMessage field supported in version 2.0.0 of the PIS API and onwards. Please make sure to implement this psuMessage field in your integration to enhance your solution with a better error handling.

Multiple approvers
The multiple approvers functionality are supported for all payment types and payment products exposed in the PSD2 API. The implementation follows the PSU roles defined and setup by the bank advisor. This functionality is only relevant for business customers.

Q: Is there anyway to retrieve information about possible approvers using the PSD2 API?
A: The PSD2 API does not expose any information about possible approvers for a created payment initiation. This is a sole responsibility of the business customers to know who can approve which payments.

Q: How is it possible to see if a payment have been partially accepted?
A: If a payment is partially accepted, the status will be PACT in the PaymentInitiationStatusResponse.

Q: Can you describe the different roles implemented for the multiple appovers?
A: I general the system supports 4 roles called A, B, C and D. A has the most privileges and D has the least.

Signing Baskets
Signing basket functionality makes it possible to authorize several transactions with one SCA by the PSU.  

Q: Can any payment products be created and added to a signing basket? 
A: Yes - all payment types are supported in the signing baskets implementation

Q: Is there a limit on how many payments can be authorized at the same time using a signing basket?
A: The general restriction is 3000-5000 payments in a signing basket depending on the size and detail level of the payload.

Q: Is it possible to delete a payment that has not yet reached its booking date?
A: You can delete the signing basket structure as long as no (partial) authorizations has yet been applied. The underlying transactions are not affected by this deletion. The signing basket as such is not deletable after a first (partial) authorization has been applied. Nevertheless, single transactions might be cancelled on an individual basis using the delete endpoint avaliable on the PIS.

Q: Is the signing basket integrated and build together with the existing signing basket functionality in the other self-service channels of the ASPSP?
A: The signing basket functionality is right now integrated with the existing outbox functionality in the Netbank of the ASPSP. If the payments are partially accepted they can be seen and managed in the Netbank also. Therefore it is crucial to make sure to use the status endpoints to know the actual status on the payments.

Bulk Payments
The bulk payment functionality initializes a collection of several payment initiation requests from the same debtor account. Bulk payment functionality is only available for business customers.

Q: Can batchBookingPreferred be used for all payment types?
A: batchBookingPreferred is only supported for the payment types "domestic credit transfers" and "payment slips (01, 04, 15, 71, 73, 75)"

Q: Is it possible to mix payment types in a bulk payment?
A: No it is only possible to add same payment types to a bulk payment.

Account Information Services (AIS)

The AIS API implements the Account Information Service parts of the PSD2 specification, and provides the following services to authorized TPPs; accounts overview, account balances, account transactions, account- and transactions details

Q: The PSU is not able to see the account via the PSD2 API?
A: If the account is not available through the PSD2 API, the PSU has to contact the ASPSP directly in relation to ask why this account is not set as a PSD2 account. Please be aware that it is only payment related accounts which are exposed in the PSD2 API. In few cases the PSU might use the wrong NemID or MitID username to try to fetch the accounts as all ASPSP might have separate logins for private and business customers respectively. 

Q: How long back in time is it possible fetch transactions via AIS?
A: The respective ASPSP have their own defined rules for how long back in time the transactions can be fetched, but the general rule is around 2 years. You are always able to get the same number of transactions via the PSD2 API as in the other self-service channels provided by the ASPSP.  

Q: Have you implemented pagination when calling for transactions?
A: The solution does not support pagination as it is right now. There have been no issues with the current implemented solution. We of course advise all TPPs to call the endpoints with care and only fetch the necessary amount of transactions needed by defining a proper timespan.

Q: Is it possible to get the account owner name as part of the accounts endpoint?
A: The accountOwnerName will be available on GET /accounts in AIS if consents are created with the allAccountWithOwnerName access type. Until now the accountOwnerName has only been available on GET /accounts/{resourceId} endpoint, but in the future it will also be avalible on the  GET /accounts endpoint.

Q: Do the PSD2 API expose Social Security Number (CPR/SSN)?
A: The PSD2 API does not include CPR (SSN) as this information is not available in the other PSU self-service channels either. We expose the account owner name in AIS, if you create a consent of type “allAccountsWithOwnerName”. This way you are able to verify if the persons name is identical with the person using the TPP platform.

Consent Handling (CIS)

Consents and consent management are core concepts of the PSD2 API implementation, and are defined with dedicated API endpoints in the Berlin Group specification. The general mechanism for validating and authorizing consents is through a Redirect SCA Approach.

Q: We have lost the possibility to create consents and fetch data?
A: The respective ASPSP might have been deprecated from BEC platform. Please see list of deprecated ASPSPs on BEC platform (scroll to the bottom of the page on the link).

Q: Can a TPP request access to only 1 specific account for the PSU?
A: The consent model only applies to Account Information APIs (AIS) and only supports global consent to all PSD2 accounts of the PSU. This means that TPP will get access to all PSD2 related accounts for the respective PSU. The Consent Management is handled between TPP and PSU. The TPP is submitting a global consent information, which is only the PSU identification, to the ASPSP for authorization by the PSU. The ASPSP is displaying only the general access to the PSU’s account to the PSU when performing the SCA. For more information about global consent model, see the Berlin Group Implementation Guidelines.

Certificates

The PSD2 APIs are only made available for TPPs authorized by a local NCA to operate as an AISP, PISP or PIISP under the PSD2 directive. Production access is only available to licensed TPPs with a valid set of eIDAS production certificates (QWAC+QSEAL).

Q: How can I receive certificates to use PSD2 API?
A: The APIs are only made available for TPPs authorized by a local NCA (in Denmark called Finanstilsynet) to operate as an AISP, PISP or PIISP under the PSD2 directive. For TPPs registered under a different national CA it is needed to passport the TPP status to operate in Denmark. eIDAS certificates (QWAC and QSEAL) cannot be ordered at BEC, but can be ordered at a certified QTSP. Please see https://apiportal.prod.bec.dk/openbanking/sandbox/start which describes the onboarding stepwise.

Q: How to replace expired certificate for TPP?

A1: If your certificates is about to expire, all you need to do is to perform a new enrollment, with a new certificate for same TPP. The enrollment with expiring certificates will be valid until certificates expires.

A2: If you need to undo/revoke an enrollment, change status as a TPP or similar, please submit a support ticket to get guidance on how to proceed.