Take me to...
The most recent Gartner Hype Cycle for Cloud Computing shows that cloud bursting, cloud-native architecture and cloud migrations are entering their most productive phase, when they begin to drive real value to the business. And on the cloud security cycle, containerization and Kubernetes have reached some level of maturity; their next phase focuses on configuration, segmentation, and access control.
For many established banks, the decision to pivot from in-house, on-premise, or self-build is strategic. Those banks seek the same speed-to-market benefits that new fintechs are deriving from Software as a Service (SaaS) offerings for mission-critical services such as payments and fraud prevention.
Alongside this, the emergence of Banking as a Service (BaaS) platforms means that financial institutions (FIs) can opt to procure their own SaaS solutions directly or through a BaaS provider.
But to execute on a SaaS strategy, from the bank’s side, there are still preparations to make. Their teams, their systems and their data must be prepared to achieve those strategic goals. The difference today is we understand how to navigate the challenges more deftly, as SaaS is mature, including for fraud prevention platforms.
Featurespace has successfully transformed its own solutions into a robust, resilient platform that delivers fraud and financial crime detection as a service. We have supported customers to launch new fintechs directly into the cloud, and we have deployed on behalf of our customers new, innovative machine learning solutions for fraud prevention into our SaaS environment.
Along this cloud transformation journey, we have learned valuable lessons about how FIs can build the best partnerships with their SaaS providers.
Dynamic scaling has emerged as a cornerstone of cloud-native architecture. When it comes to fraud detection, this does not just benefit financial institutions. Online retailers, gaming platforms, public services — they all need systems capable of scaling horizontally to be efficient and effective at meeting spikes in demand as well as optimizing for troughs.
There are some predictable transaction highs in payments: large sporting events for gambling platforms, for example, or Cyber Monday and Singles Day deals for eCommerce platforms. If the technology underpinning the solution lacks the ability to scale horizontally, it could cause it to degrade, or even crash during those peak events. The alternative is the vendor must overprovision for the other 362 days each year when transaction activity is much lower, which eats into profit margins.
A similar problem exists in relation to fraud and financial crime and SaaS. Without horizontal scaling, vendors face the choice of throttling their transaction throughput during their peak earning phases or turning off their anti-fraud systems and risking high fraud losses and potential non-compliance with anti-money laundering regulations.
Given the ever-increasing growth in payment transactions, all financial institutions, merchants, and those who serve them need solutions that can scale efficiently and effectively in response to customer demands, but without overprovisioning during less-busy periods.
Seamless scaling also needs to be complemented by seamless upgrade and change processes. Vendor solutions need to be rearchitected to roll out upgrades and new functionality with minimal risk and minimal effort for the FI. In the event that an upgrade fails, it needs to be easy to roll back to the previous version, too.
Multi-version support in SaaS may not be common in consumer platforms (think Netflix or Amazon Marketplace) but given the potential business impact of a change to a fraud-detection-as-a-service platform, customers need the flexibility to choose when they want those changes to take effect. In addition to managing the business impact of change from the vendor side, a robust and secure sandbox is a key feature that allows FIs to test configurations of their SaaS platform.
Flexibility of choice should extend into choice of cloud, too. Data sovereignty regulatory requirements must be considered alongside co-localization or existing cloud deployments, and their impacts on latency. FIs need solutions that can be deployed in the cloud environments of their choosing, whether that’s by geographical location or cloud operator. In the future, multi-cloud environments could potentially become the norm for large organizations when distributed systems span multiple clouds but operate as one unified system. Current solutions need to be compatible with this colocation approach.
For FIs, these are the three areas of evaluation (excluding security and compliance which apply universally) for vendors when considering a fraud and financial crime SaaS offering:
For FIs looking to shift to a SaaS solution, a lot of the preparation exists within their own digital transformation workstreams.
It is highly likely that a bank will already have anti-fraud and anti-money laundering (AML) solutions in place, and probably at least one full time employee (FTE) who manages those systems full-time. A key aspect of a successful SaaS deployment is to recognize that the bank is already an expert in the systems it has built.
From that perspective, moving to SaaS can be likened to the evolution of global shipping. Until the 1950s, goods were shipped in all different sized- and shaped- containers, making transportation of them difficult. Now, the same goods are being transported, but the mechanism by which they flow around the world is in standardized containers, so all goods in containers can go on any ship, train, or truck that supports a standard container. In SaaS, each vendor provides a standardized solution which is then integrated by customers. This benefits the vendor in that they can focus on evolving their standard technology instead of customizing it, which ultimately benefits the customer. Incidentally, this is the same metaphor used by containerization technologies such as Docker and Kubernetes, which are frequently used to build SaaS products.
When consuming a SaaS offering it is important to remember that many of the change management and scaling efficiencies are predicated on the standardization of the offering itself. Organizations should be ready to make some changes to enable them to use SaaS, they’ll need to adapt the data flow.
Fraud and financial crime teams will need to prepare their data to map to the vendor schema. If this requires changes or workarounds, they should look to achieve this through translation and orchestration of that data within their own systems, rather than within the vendor system (as they might have done with traditional enterprise deployments. By restructuring to the new standardized data flows, they unlock the benefits of a SaaS solution.
Making this interface easy to maintain, even as they manage changes within their own systems, should be part of the groundwork for a SaaS shift. FIs may consider leveraging an API manager or gateway solution as the interface into the SaaS provider.
Outside of technology preparation, there is due diligence in terms of risk and compliance requirements. The transition to SaaS requires some modernization in how risk teams evaluate vendors, and a change of expectations. In SaaS, vendors can reserve the right to change the underlying technologies of their platform, a departure from the on-premise contracts of old.
It is important to align compliance expectations and requirements with the reality of what a SaaS vendor can provide. The work here is to understand everything you need from a compliance perspective, then make sure those are all accounted for in the service-level agreement with the vendor.
For FIs, here are two things to keep in mind when preparing your assets for a SaaS shift:
Kubernetes is one of the key technologies that has enabled companies like Featurespace to build SaaS solutions. The migration of FIs to using SaaS services is (I think) largely driven by the general acceptance of SaaS as an acceptable model for FIs, and the rise in the number and quality of SaaS providers ready to meet their needs.
Kubernetes for container orchestration is a technology that creates ease of change and upgrade in combination with other complementary technologies.
Moving to application-level state makes it possible to deploy an application before configuring it and to iterate configuration without redeploying it. This is an enhancement that can be made to an application which is complementary with using Kubernetes. Once done, configuration changes can be made in the application layer rather than the infrastructure.
It is typical for SaaS vendors to offer at most a small choice of versions of their standard platform, which enables them to invest more of their research and development (R&D) budgets into innovations and improvements, without the overhead of legacy versions to maintain or custom deployments. The ease of change means developing and deploying new innovations into the platform can be the focus for the vendor, and more easily consumed by the FIs.
Kubernetes helps SaaS providers develop robust and dynamic systems that then have a host of useful feature for customers to consume. Kubernetes makes horizontal scaling of resources quite easy provided the underlying application can support that. It also provides powerful mechanisms for deploying systems that can result in quicker and more robust deployments and upgrades. In the past, traditional on-premise deployments, or products that have been lifted and shifted to the cloud without architectural change, required time-consuming configurations for FIs to begin processing. But by investing in a cloud-native approach while migrating to the cloud the benefits of cloud technology such as elasticity can be leveraged directly, resulting in an improved overall product. Those improvements might include simpler deployment, easier scaling, and greater robustness. Targeting deployment at Kubernetes specifically can result in a product that is more portable between on-prem and cloud, and even between multiple cloud vendors.
Choosing a SaaS partner does require some strategic clarity, but once the partnership is in place the ongoing simplicity of consuming fraud and financial crime prevention services makes that initial effort worthwhile.
Given the speed of change and innovation in payments and financial services, it’s clear that the technology refresh cycle is reaching the point at which legacy, customized on-premise deployments are too cumbersome and complex to keep up.
A transition to a SaaS strategy now seems inevitable. It has become a question of whether you can make that move with confidence.