Q:
Do you support sole-trader/freelancers accounts and small/medium business (SMB) accounts within PSD2?
A:
Both accounts are supported but it depends on the agreement the PSU (Payment Service User) has with the bank, meaning personal agreement or business agreement. Sole-trader accounts could be in personal agreement or in business/sme agreement.
Q:
How to distinguish the sole-trader from small business account? Do you need to use different endpoints to access them?
A:
Based on the agreement. There are separate APIs for personal and business/sme segment customers.
Q:
Does Open Banking access for business/sole-trader accounts require additional consents or other steps?
A:
Consents are needed, but the same process applies. There are also different scopes in consent. Please refer to:
Business Access Authorization API
Q:
Where user rights and roles are managed for business accounts?
A:
Authorizations (user rights) are stored in the bank's local legacy systems.
Q:
What authentication methods are available in the business flow?
A:
There are several. Please refer to:
Redirect Access Authorization (Business Access Authorization API)
Decoupled authentication (Business Access Authorization API)
Q:
Do you support multi-authorization (2 people authorization) for PSD2 business accounts? Is it only for PIS?
A:
Yes, customers can choose to approve a payment by 2 persons, known as 4 eyes confirmation. It is for PIS only. Please refer to our Business PIS documentation:
Q:
Do you provide the following information in the AIS response for business: organisation (company name), company registration number, tax number, VAT number, organisation address, name of the PSU who has consented to the access?
A:
Yes, please refer to:
Q:
What are the payment schemes supported in PSD2 for business and what are the fees for them? Are there transfer limits?
A:
We offer several products like: SEPA credit transfer, account payments, salary, pension, own transfer and cross border. Yes, there are limits - if the payment reaches the limit you will receive an error message indicating this.
Q:
Do you support payment cancellations?
A:
Yes.
Q:
Is the PSU name exposed in the PIS flow?
A:
The PSU name is not present in the PIS response. Creditor name will be reported.
Q:
Do you provide settled payee and settled payer status?
A:
We don't provide such functionality.
Q:
In the response to:
GET business/v4/accounts
you return account_name and account_holder parameters. How do they differ? Which one should we use for account owner name: account_name or account_holder?
A:
A default account name in Nordea is a name of the product. However, customers are allowed to set an alias for the account and by doing this change the account_name - this parameter does not relate to the owner of the account.
Account_holder parameter should be the name of the account holder (owner). Refer to:
Get list of accounts (Business Accounts API)
Q:
Is it possible to approve domestic and cross border payments with the same approval?
A:
It's not possible to sign domestic and cross border payments together, as there are separate APIs for each.
Q:
Regarding "4 eye restriction" and a field signed_by_current_user, your documentation:
Get a list of payments created for the user (Business Payment API Domestic Transfer)
states:
"If the value is true, it means that the current user is the first signer of the payment, and cannot sign it again. If the value is false, it means another user was the first signer, and the current user is allowed to sign it the second time to confirm the payment (does not apply to SE GET single payment endpoint)."
However, while testing, after user A signed the payment (first sign) you responded with: "signed_by_current_user": false" but user A was the first signer. Please explain how this could be and how the flow should be working?
A:
We provide signed_by_current_user value based on who is logged in into TPP application. However, when signing, any user can be used to sign the payment and as long as he has the power to sign it, he can do so using link/data generated by someone else.
Then, it might be, that there were two user accounts - e.g. A and B. User A signed in via Open Banking API (OB API), created the payment and started signing. Then by mistake user B was used to sign the payment. This can happen and is supported. So now we still have user A signed in to OB API while payment was signed by user B. This means that from a perspective of signed in user he can sign the payment because user A did not do so yet.
Q:
Can I use a TPP to access my account information if I have Nordea Business Konto-Kik?
A:
Yes, you can. If you experience any issues with this, please verify that you have access permissions to the account. If you do and the issue still persists, please request your TPP to contact:
Nordea Open Banking technical assistance
Q:
We observe that some payments fail due to two main reasons:
- The amount exceeds the limit for transfers/payments from the user's account
- The payment is blocked in the AML (Anti-Money Laundering) controls and gets suspended
What is the expected state of a payment when it falls into above categories? For example, we receive a 503 error stating that the payment exceeds the security limit. What would be the state of the payment in that case? How do we know when it is released and what are the possible states?
A:
The payment status depends on at what stage the error was thrown. If the error response was received at payment initiation, then the payment is never captured. PSU needs to initiate the payment again after considering the amount limit on the account.
In case of a payment being blocked due to AML controls or any other fraud prevention, the payment may be put on hold. In those scenarios, the PSU needs to contact the bank and resolve the case.
In case of the payment being blocked after confirmation due to payment limits, then the payment will remain in Confirmed status until it is possible to book the payment. There are also cases, when the PSU needs to provide a second confirmation via SMS. Open Banking API is not aware of such occurrences and so can't notify when a payment can be released.
Q:
We encounter payment initiation failures due to invalid characters in the message. What characters are allowed so we can make that validation ourselves?
A:
Please refer to: Special characters in message fields (creditor/debtor/beneficiary name)