Fallback solution

Bankdata offer a mobile banking solution for both private and corporate customers.
The solution is offered using a native Android and iOS app communicating with middleware hosted by Bankdata. 

Security elements

Every request from the app to the middleware is validated for presenting a valid mobile bank session.
To obtain a valid session, which includes a set of mandatory cookies, the customer needs to enroll with MitID once to create a device binding linking a token to the device that must be provided on every login together with user id and mobile code.
The MitID login page is loaded in a WebView and the solution is only designed and tested to run in a mobile app.

All calls regarding customer authentication are encrypted/decrypted with a secret that is randomly generated on the mobile device.
The secret is encrypted with a public key and exchanged with the backend. Bankdata will offer any approved TPP with this public key.

To be able to create payments a public/private key pair needs to be generated on the mobile device.
The private key is stored on the mobile device and is used to sign the payment data.
The corresponding public key needs to be provided during first time enrollment with MitID.

All traffic need to be secure using TLS 1.2.

Architecture

The native apps access the middleware which is a set of REST-services.

E.g. for private customers.

E.g. for corporate customers.

 

The current set of middleware services can be requested by contacting api-dev-support(a)bankdata.dk.

Web bank services

Bankdata offer an online banking solution for private and corporate customers.
The solution is offered by utilizing two types of portlets (IBM Portlet API or JSR-286) to give a web portal experience.

Security elements

Every request from the client to the backend is validated for presenting a valid online bank session.
A valid session includes a valid MitID session key and a set of mandatory cookies.
The current set of needed cookies can be requested by contacting api-dev-support(a)bankdata.dk.

All traffic need to be secure using TLS 1.2.

Architecture

An interface is implemented as a JSF portlet. This requires you to introspect the client html to utilize the relevant forms and actions, to activate the backend accordingly.

The JSF portlet interface rely heavily on the use of specific urls, and them being statefull means that one cannot rely on using static urls.
Details on this can be offered by contacting api-dev-support(a)bankdata.dk, as we cannot detail the use due to security.

Identification of Third party

In order to be identified as a third party you must follow the list of rules stated below. These rules apply to both the Web bank, mobile bank and the Online Bank Service.

This is how the TPP should make itself known:

• TPP’s must always identify themself by presenting their eIDAS QWAC certificate as part of all requests.
• The eIDAS QWAC certificate must always be stated under the request parameter "x-bd-tppcert".
• The eIDAS QWAC certificate must always be delivered Base64-encoded.