Some core system suppliers promote having a sandbox as being a shortcut to evaluating whether their solution will meet potential users’ requirements. However, a bit like the childhood sandbox experience, there is a risk that taking such a shortcut will not end in the happy smiles anticipated.
Just to be clear, this is not about the popular virtual game called Sandbox. This is about the type of sandbox one finds deployed in the local FinTech incubation hub or a software supplier’s testing environment. This type of FinTech sandbox, or application programming interface (API) sandbox, is typically pitched as an environment that innovators and testers can use to mimic the characteristics of a production platform and simulate responses from all the systems that an application interacts with. Sounds great, does it not? But does it really work like that when it comes to evaluating complex use cases and scenarios? In the post-trade securities custody world, with its multi-participant value chains, or even the domain of highly automated lending, where accurate multi-factor risk assessment is critical, does a sandbox really provide the confidence levels needed to make informed system selection decisions?
There is absolutely a case for a sandbox when it comes to testing very simple functions. For example, in the payments space, PSD2 has revolutionised the value chain, allowing third parties to act as aggregators of information and initiate payments. Here, the sandbox concept has come into its own. Testing a simple API that allows one system to ask another for an account balance is not complex. The qualitative information returned by the API (i.e. is the balance actually correct?) is less critical to the testing outcome than the quantitative aspect (i.e. can the process handle the anticipated volumes?).
However, confirming that more complicated business processes, with deeper and broader functional requirements, can be efficiently implemented and achieve the desired results is unlikely to be achieved through the testing of APIs in a sandbox. In order to handle such potentially intricate use cases, systems need to be fine-tuned and adapted, ideally through flexible parametrisation, or at worst through coding, to reflect the specific flows, computations, decisions and procedures of all the stakeholders and participants in the ecosystem.
To use an analogy, if one was looking to buy a new electric car, would it be enough to test the accelerator, brake pedals and each motor on each wheel separately, to sit in the seat outside the car and check that it moves backwards, forwards, up and down, to switch the sound and navigation system on and off, plug the battery charger in and out, etc.? Or would one expect to test drive the car with all the components working together in unison, ideally under various road conditions, in order to have the confidence to invest?
In reality, there are no shortcuts. Accessing a sandbox full of APIs that rely on generic data, standard flows, common calculations, and simplistic business rules may grant some superficial, short-lived happy excitement, but the feeling will not last. Indeed, it is probably a waste of time and resources that could be better spent, and for some, it may well end in tears. A far better approach is to work closely with the core system provider in order to demonstrate that the proposed solution offers the built-in flexibility and functional coverage to meet the current as well as envisaged future business requirements and use cases specific to the needs of the institution. This way, the end result is bound to be all smiles.
Read the original article here.
