The concept of a ‘sandbox’ is not new to banking, ranging from an idea factory type of approach to a dedicated lab environment whereby practices are shared before solutions are deployed.
The latter is the BankiFi ConsentBox, designed from both a developer’s angle as well as the banks angle fuelled by experiences of working with a range of banks on CMA-9 and PSD2 strategies around account aggregation across a wide range of APIs in a multi-bank environment.
Furthermore there is a distinct lack of standards around APIs, so reuse of APIs once captured is key as well as offering developers an environment where they can have access to both non-bank as well as bank data in a ring-fenced manner. All these requirements can only be met through a universal sandbox.
Such an approach has an enormous strategic benefit to banks. By offering a ConsentBox that has multiple bank and non-bank APIs available from the banks developer portal, the bank creates a very “sticky” service for developers which becomes the cornerstone of the Bank as a Platform (BaaP) strategy.
Any bank that has this strategy can become the “go to place” for developers, enabling that bank to create a whole new customer segment and explore new business models around revenue sharing and product distribution.
The first option is to deploy the ConsentBox independently of the BankiFi platform. This model assumes that the sandbox is a back office and that access to it is achieved through the target bank’s developer portal and API Gateway/Management product. The Aggregation Service is a reference service that can be shipped with the ConsentBox and the 3rd party apps are those that would consume the APIs connected to the ConsentBox via the bank’s developer portal.
The ConsentBox can also support 2 different sets of APIs, the first being the CMA-9 standard read/write APIs and the second being an aggregated (normalised BankiFi specific) API that supports the CMA-9 read/write APIs and other Banks PSD2 AIS/PIS APIs. It also includes the support of the CMA-9 security specifications around token issuance that conforms to OAuth 2.0.
The second option is to deploy the ConsentBox with BankiFi. The benefit of this option is that consent management and OAuth token issuance and management are provided as services within BankiFi, taking this requirement away from any third party application connecting to the platform. So, for application providers that do not wish to build these services themselves, or, for application providers who just wish to build applications that are predominantly running within the UX layer, these critical services can be consumed from BankiFi. As with the first option the Aggregation Service can be deployed as a reference application whereas the other option is for 3rd party providers to connect via BankiFi through the bank’s developer portal.
The BankiFi platform does not only provide the stand-alone development and test environment, but also enables a staging platform towards live production where the BankiFi platform can actually point to both the ConsentBox end points and the actual end points from other banks, whether those are CMA-9 Open Banking endpoints or PSD2 compliant interfaces. This enables application providers to point directly to those other banks through a white labelled infrastructure positioning the bank as either a “Bank as a Platform”, or simply a TPP that provides AIS/PIS Aggregation capability for either bank developed or 3rd party developed applications.