Reuse instead of rebuilding
Many financial service providers are currently discussing open banking. After all, you have to keep up with the latest technology. But is it safe for a bank to offer open banking and thus access to sensitive data? Actually, it’s a paradoxical question, because most banks that are thinking about using an open banking solution already have the necessary infrastructure for such an undertaking. After all, e-banking also places high demands on technical security standards. By intelligently using this existing infrastructure, proven security features can be reused, which even simplifies the implementation of an open banking solution. One important aspect, for example, is the protection of the new PSD2 APIs against unauthorized access. For this purpose, it is recommended to use the already existing security infrastructure, as it has already been audited and has no security gaps. At ubitec and our open banking platform ubix2b, we therefore pursue an approach that uses and integrates the proven security infrastructure of our customers. Existing firewalls and identity providers are integrated to ensure the separation of powers between the individual systems. The resulting architectures follow the so-called best-of-breed approach: Each component specializes in a certain functionality, which it again makes available for other systems.
Track data persistence closely
Let’s take a look at the example: The first point of contact for third party providers (TPP) is usually a web application firewall that checks the requests and blocks potentially malicious ones. At the same time, the firewall checks the centrally issued TPP certificates. In this way, the firewall ensures that only registered third party providers are granted access. In addition, all communication between the banking system and TPP requires that the data sent and received via TLS is encrypted. However, a firewall alone is not enough: data persistence should also be closely examined. In such a process, it is crucial to pay attention to what data is stored and made available where. All personal identifying data must be persisted in a specially secured network zone, while metadata for the use of the APIs, which do not allow any conclusions about the customers concerned, can be kept in a DMZ. In addition, attention must be paid to the logging of the individual applications. In this way, it is possible to avoid sensitive data appearing in a log file.
Consumer protection through consent management
However, the security of an open banking solution is not only based on the infrastructure used. The PSD2 framework also plays its part with the prescribed Consent Management. Consent Management manages the access of TPPs to customer data. It is important to understand that TPPs are not automatically granted access to the data of all customers when they access the implemented APIs. PSD2 stipulates that customers must explicitly agree before a TPP can access their data. In order to ensure this, banks use a special authorization process to obtain customers’ consent to the disclosure of their data. This authorization takes place exclusively between a bank and its customers, so third-party providers cannot influence it in any way. In addition, the granted consent applies only to the relationship between the customer and this specific TPP. If another third-party provider wishes to access the data, the authorization must be repeated for this provider. In this way, the bank ensures that the customer has all the necessary information on the authorization granted. In addition, established login and two-factor authentication methods protect the authorization process against attempted misuse. In this way, not only are the same security standards maintained as in an e-banking application, but the bank also uses already established security infrastructure. And to anticipate any remarks: No, it is not too complicated. Security requirements in the open banking environment are not to be trifled with. As the saying goes: better safe than sorry!