The Administrator Portal is the GUI Interface for Backoffice Users of the client to access and administer the Open Banking Platform. It provides the following modules:
Initiating Party and Subscription Management
User and Access Management
Service Provider Management
Banks can set up Providers for Initiating Parties in their environment. Those Service Providers do the technical integration for them and make it more easy to offer payment means to the customers. So (e.g. smaller) Initiating Parties can avoid the effort of integrating to the routing services systems for each payment mean by choosing a PSP as Way of Integration during the onboarding The service provider needs some configuration on the system, e.g. they have to provide a valid certificate and some mandatory data. In order to maintain the service providers per service to be offered to Initiating Parties as connection method, the Open Banking Platform provides the Service Provider Management.
Which features are provided?
The Service Provider Management enables Initiating Parties and Bank Backoffice Admins according to their access rights to maintain the following features: Service Provider data, Account data, Service Subscription Data, Technical & Security data, Setup, check, manage, deactivate existing service providers.
User Login Functionalities
As standard the Backoffice includes an access control via personified login page, the user can insert his name and valid password into the according fields and submit via the Login button. If the entered data don’t match, an error message (Authorization failed) informs him and after repetition and successful validation he is logged in the application. In case of forgotten password, additionally a link “Forgot Password” available. Using it, an according dialog starts to renew the current password.
Also as standard solution our Backoffice includes an user login with 2FA Authentication, which can be activated per acquirer bank / tenant via the configuration management. Once activated the existing username/password is used as first factor, the smartphone functions as second factor. On the smartphone an One Time Password (The user has to install an OTP generator on his smartphone, e.g. FreeOTP Authenticator). can be used to provide a temporary valid OTP, which has to be entered into the login form.
In addition the latest possible date from which the use of the OTP feature becomes mandatory for users is configurable on per acquirer / tenant: In this case an individual “Start of OTP” is stored for each user (new or already existing), who does the first login for his acquirer via 2FA. During every login now is checked, whether the individual "Start of OTP" date of the user is already exceeded and how many days remain until expiration. Before expiration, the user is able skip the OTP secret verification (via an according button on the GUI), afterwards he has to verify and register an OTP secret.
As login mechanismen to the bank systems we provide Web Single Sign On functionality (Web SSO) using credentials for authentication, which are a unique username and password: By using this functionality the first step it is checked if the user is already logged in to the authentication system. Users, who are already signed in, are marked as Single Sign On Users in the system and are granted access immediately. If not, the user is directed to the authentication system to sign in. For each session, the user must first sign into the authentication system with a unique username and password. The authentication system uses a token for the session that stays in effect until the user logs out.
After the authentication process is running, the authentication information is passed to the application, requesting verification of the user.
To login the OB Platform via Web Single Sign On (Web SSO) the banks offer special URLs. The Certificate, which is needed for the securing the Web SSO connection, can be uploaded via the Merchant and Subscription Management Module.
Certificate Management
Our Certificate Management provides a central management for certificates and is operated from the Backoffice GUI. As a consequence of PSD2 this functionality allows to manage hundreds of certificates and to automatically update related keystores in all associated Routing Service Instances during runtime: Certificates can be refreshed automatically during application runtime of the Routing service.
The Certificate Management allows creating Qualified Website Authentication Certificates (commonly known as TLS certificates) and Qualified Electronic Seal, certificate signing request (CSR). Whereas the key pairs, consisting of a private and public key, for QWAC CSRs are generated by the module itself; keys for QSEAL CSRs are derived from HSM Boxes using the restcrypto-server application.
Once the official signing process of QWAC and QSEAL CSRs is completed by an external certification authority (CA), the resulted certificates can be uploaded to the Certificate Management Module.
At last a functionality within the module allows the user to send the certificates (as for QWACs the private keys as well) wrapped in a keystore to the Routing Service Instances at runtime.
If the same certifiacte (fingerprint) is stored on merchant and subscription level, the certificate is only stored once. It will only be deleted, when the certifcate is deleted on both levels on Backoffice side.
I is possible to Upload Certificates for the API authentication in the BO on merchant level additionally to the ones on subscription level. This is allowing to use the same certificate for all subscriptions.
Transactions Processing/ Refund Processing: Overview of all IP running on the system
Initiating Party Ticketing/Support
Document Management
Dynamic Creditor Account Lookup (DCAL)
We provide a Dynamic Creditor Account Lookup Service , which can be switched on or off for each of the tenants’ Initiating Party (by the tenant’s Backoffice Admin). If the DCAL is activated, up to ten additional creditor accounts can be set up. This service will only be used for Initiating Party without Sub Ids.
In case, the DCAL service is switched off, but DCAL entries already exist, those entries will not be deleted. When DCAL is switched back on, the data are available again. Clients, who have access to the Backoffice as Admin User can select the DCAL option itself in the Tenant GUI and on the Initiating Party GUI , in the PIS service configuration.
Via the DCAL screen the on/off switch can be managed very easily and on the DCAL table creditor accounts can be created, updated and deleted.