Fabrick’s New Model for Test Data Management 

In the era of open banking in Europe, Milan-based, open-API platform Fabrick is one of the first endeavours of its kind, designed to link specialist fintech providers of financial services to other banks. Fabrick was launched only in June 2018, but has already signed up dozens of fintech providers of payments, banking and asset management services. It is, in effect, a plug-and-play online banking marketplace leveraging innovation from fintechs  – which are specialists in their chosen services markets – to help small and medium banks to build up their online banking catalogue. In Italy’s fragmented banking market, where small regional and local savings banks retain a large market share, this could prove to be a winning formula. The challenge in all this is the technology required to connect those APIs, and in particular to facilitate testing APIs that connect customers of different firms without breaching EU data protection rules. We spoke asked Fabrick’s Giulio Rattone to explain. Q: How do you approach software quality in a multi-party project like Fabrick? A: We use a very straightforward approach. After gathering technical metrics, such as the number of API connections required, and setting objectives for each of them, we then have to work with various stakeholders in the business and external partners. Fabrick isn’t a single application, but a platform connecting multiple organisations. Therefore, the overall software quality is based on that of each individual producer. We discuss with the stakeholders what will be necessary to achieve and maintain an overall standard of quality. We then actively help all our external partners to reach these goals. For example, we produce quality reports for our partner organisations. Tackling quality within a partner ecosystem is a new scenario for us and we are finding out it’s very different to “playing at home” when every strategy is very easy to field test. Q: What are some of the pitfalls you’ve encountered and how have you avoided them? A: The main hurdle we faced was that there was no roadmap. Prior to us embarking on this experiment, nobody had created a banking API platform on this scale. The business model is totally new. So we’ve had nothing to measure against. This applies to both the technical architecture and the business model. The second challenge was the monetisation. We took the time to figure out what our revenue streams would be. As we see it, we create value for very different types of businesses – from start-ups and fintechs to incumbent banks. We see open banking not as a single business model, but as a bundle of several business models. We had to align our monetisation strategy accordingly. Q: What was the key technical challenge and how did you tackle it? From a technical perspective, the challenge was to secure the open architecture. When developing the API architecture, we had to use the banks’ infrastructures, including their testing and staging environments. This posed a challenge in terms of documentation, sandboxing and a number of other areas. One obvious example was the data layer. When developing a new app, the TPPs needed to test it with real customer bank accounts. Our approach to data management in sandbox environments is what I would consider one of our biggest successes this year. We had to tackle it creatively, to fit our platform structure. Banks are connected to fintechs via an API layer. Usually, a bank’s customer will use their banking credentials to access the third-party provider’s platform. Our problem was that while developing and testing the platform, we couldn’t directly use customer credentials to test the accessibility. One approach would have been to simulate customer accounts to test the API access. However, in this case, we would have had very limited test data. So instead, for the sandbox environment only, we created a new authentication schema. It enabled us to test the login using existing customer accounts, but without viewing the strong customer authentication [the SCA, which refers to the two-factor authentication required by EU law to verify online transactions.] Doing this allows us to associate a set of customer accounts with a single third-party provider, in order to develop and test. The provider can then use these accounts to test the API access only in the sandbox environment, without viewing the SCA. We also completely anonymise the data, using text recognition algorithms to detect customer names and remove them from the testing dataset. This allows the third-party provider’s developers access to real data, without compromising account security. It’s an approach to anonymisation and security that we had to build from the ground up. Giulio Rattone will give an in-depth presentation on the challenges and opportunities in open banking at the QA Financial Forum in Milan. To register for the event, click here.