Electra openAPI

Use

A new electronic channel to provide open banking services.

The second European payment services directive No. (EU) 2015/2366 (PSD2) imposes a statutory obligation on banks and financial services providers. Under this regulation, banks have to grant Third Party Providers (TPPs) secure access

  • through a standard, open API (Application Programming Interface)

  • to account balance and account turnover information, and

  • to initiate and authorise payment transactions.

The European Banking Authority drafted a Regulatory Technical Standards (RTS) document for this regulation. The document provides that affected financial institutions must provide appropriate support for using APIs, implement Strong Customer Authentication (SCA) solutions, use open communication standards and monitor transactions, among other things.

The European regulation is competition- and technology-neutral. Accordingly, it does not set out mandatory API standards. Still, to support uniform operation throughout Europe, European regulatory authorities selected five API standards implementation initiatives, of which Cardinal chose the German Berlin Group – NextGenPSD2 standard, which seems to be becoming the most popular API standard in Europe, as the basis for implementing the operating logic of Electra openAPI.

To fulfil the needs of our banking partners already using other Electra channels, the openAPI product has a modular design. This allows banks to support certain elements of the services with their own solutions, while the missing functions can be implemented by interfacing Electra openAPI components. Unless the bank already has some functionality in place for its own open banking architecture (which can impose restrictions), the combination of all Electra openAPI modules can provide the entire service set* required for open banking.

Electra openAPI supports the OAuth2, decoupled and embedded authentication modes defined by the Berlin Group.

The new electronic channel also allows multiple signatures (multiple SCA), an essential functionality to manage a company’s daily finances.

*Except for the API Management Portal, which Cardinal does not deliver with its full-functionality solution at the moment.

Advantages of using Electra openAPI

  • Once installed, Electra openAPI ensures interoperability between all Electra channels: openAPI ↔ Client Program ↔ Netbank ↔ MobilApp. (An order added by a user through one channel can be retrieved, signed and sent to the bank by another user using a different channel.),
  • It offers the use of multi-signatures, an indispensable function in corporate environments,
  • Modular architecture – it can be adapted to and integrated with already implemented elements of the bank's open banking service,
  • Compliance with the Berlin Group standards, the most widely used standards in Europe; upgrades to remain compliant with the future releases of the standards,
  • By integrating all of its components, it is possible to implement a complete open banking service solution,
  • As a result of future development, it will be able to support additional API standards initiatives later on,
  • The openAPI solution automatically uses the logs, the archive, the monitoring functions and the statistical module of the Electra system,
  • All openAPI operations are recorded in the Electra customer log and can be viewed under sent orders also when using other Electra channels,
  • Bank administrators can monitor and prepare statistics on its operation along with that of other Electra channels on a single interface,
  • Users can initiate and carry out transactions with the access rights set up for them on other Electra channels.

Integrability

Modular elements of the Electra openAPI channel:

  • Channel rights management server (to store and manage users' channel rights and customers' channel restrictions)
  • Channel rights management front-end system (the set of new functions integrated into Electra services (Client Program, Netbank and Webadmin))
  • TPP Management module (to send callers the list and details of TPPs available at the bank)
  • Consent Management module (to receive and manage the consent management APIs defined by Berlin Group, to store consents and assign unique identifiers to them)
  • AUTH2 server: Authentication and Authorisation module (to provide authentication and authorisation services to the openAPI solution; its functions ensure strong customer authentication (SCA) of users and verify if they have appropriate access rights)
  • AISP server: a module processing AISP and PIISP requests (to manage AISP and PIISP requests received from TPPs)
  • PISP server: a module processing PISP requests (to receive and manage payment APIs defined by Berlin Group)
  • API router (to provide a common, single access point for various systems of the bank to manage incoming TPP calls)
  • API add-ons
  • Mock API router/server

Payment Initiation Services (PIS) provided through Electra openAPI:

  • Initiate one-off single- and multi-item payment transactions
  • Initiate standing orders
  • Modify one-off single payments
  • Query payments and payment statuses
  • Initiate, modify payment authorisations, query authorisations and authorisation statuses
  • Delete payment

Account Information Services (AIS) provided through Electra openAPI:

  • Query accounts
  • Query the balance of an account and the transactions made on it
  • Query the details of a specific transaction made on an account
  • Generate certificates of the available balance

Consent services provided through Electra openAPI:

  • Create new consents
  • Modify consent resource
  • Delete consents
  • Query consent status