SaaScada – data-driven, customisable core banking system

The graph above shows the three levels of challenge for the provision of embedded finance products and services. (1) Customer management coordinates the interaction with the customer throughout the customer journey. (2) The middle level (service management) is central to the scalable provision of services. This level integrates the connection to third parties and relevant data (e.g. transactions, balance queries, etc.) with the bank’s core banking system or third-party partners. (3) System management coordinates system support with the company’s own core system, the integrated peripheral systems, and the integration partner applications.

Due to their established application architecture as well as the service and product landscape, it is often difficult for banks to leverage the opportunities offered by embedded finance. This is where SaaScada comes in, setting itself apart in the core banking system market with a new model for service/product configuration and pricing. SaaScada has a dedicated service management layer for the integration of various third-party providers (TPPs) into a bank’s offering. The flexible product engine also allows product customisation using predefined elements from a composable product construction kit which removes the need to purchase product modules. SaaScada is using these elements to open new opportunities in embedded finance.

SaaScada was founded in London in 2017 by Nelson Wootton and Steve Round. The two had previously launched the Change Account, an account for underprivileged people who would otherwise have been unable to open an account with many banks. Similar considerations gave rise to the idea of helping companies of all sizes to offer financial solutions. SaaScada was born, a cloud-native core banking platform with a microservice architecture designed to reduce system interdependence at code level and thus overcome the challenges of monolithic legacy systems, such as backward compatibility.

SaaScada wants to give its customers a best-of-breed strategy with a core that is as focused as possible. The SaaScada architecture comprises an integration layer with service management elements  (see above). This allows other services, partners, or peripheral systems to be connected using open interfaces.

Thanks to this architecture, SaaScada can also be used as a modular add-on for existing core banking systems, providing a sole service management layer within an existing banking platform. Regulatory frameworks are implemented individually in SaaScada with the help of local partner systems or peripheral systems. Its focused functionality and ability to cover local requirements through partners mean that SaaScada can be used almost universally as an integration layer for a core banking system or as a posting engine.

A key differentiator of SaaScada is the strict segregation of transaction, item, and master data. The immutable transaction ledger enables every point in time to be reproduced in real-time from the customer’s perspective. The segregation of transaction and master data (e.g. customer or product data) permits the scalable mapping of individual products using the Product Configuration Engine. For established banks, SaaScada thus offers the opportunity to launch new products and services comparatively quickly and at low cost. Pre-configured modules are used for this purpose, which can also be supplemented with further, customer-specific modules if required (see «Product configuration» for more details).

SaaScada defines its core banking architecture as follows:

SaaScada’s core banking system with booking ledger, integration framework and data interpretation represent the middle layer (service management). The individual components of the middle layer are designed to be connected to other customer or partner systems by open interfaces. The booking ledger ensures that data interpretations (e.g. all transactions above a certain value, accounts with a certain balance, or interpretations for accounting software) can be read and processed by existing core banking systems.

In the customer interaction layer (customer-owned services/partner ecosystem), SaaScada sees the services owned and operated by the banks. This includes all customer services offered by the bank across all channels.

The customers or partners use SaaScada’s APIs to connect to the core banking engine (middle layer) and retrieve information (e.g. available account balance). The APIs can be used by the digital banking service of the customer’s bank or service provision partners, for example, to access accounts or transactions. Through needs-driven integration, SaaScada can selectively control the integration of customer data, for example.

This means that cards, payments, or stock exchange activities can be integrated for customers in line with the respective business model, but further such activities currently must be mapped in the existing core banking system (e.g. corporate actions); however, there are plans to map individual services in the future. Not least from a regulatory perspective, the core should be kept as agnostic as possible so that everything SaaScada is building can be used in different jurisdictions.

SaaScada positions itself as a core system provider for different branches of the financial industry as well as for the implementation of embedded finance services in other industries. At present, its customers are mainly FinTechs and (challenger) banks, e.g. 360pay and Relio from Switzerland or Allica Bank from the UK. Relio has been awarded the Swiss Fintech Licence lately and uses SaaScada for connecting to the payment infrastructure and the Swiss National Bank, while Allica Bank uses SaaScada primarily for the mapping of payment accounts for SMEs. SaaScada will enter the banking market by offering banks lower provisioning costs per account and subsequently expanding the use of SaaScada services on an ongoing basis.

The banking capabilities offered by SaaScada can be used for different customer segments, including retail customers (e.g. payments and mortgages), corporate customers (e.g. payments or current account products) and private banking and wealth management (e.g. the trading of traditional and digital assets). In the case of the latter, SaaScada is currently enabling support for equities in the form of ETFs but more complex securities (e.g. corporate actions, etc.) will continue to be managed by the bank’s existing core banking system for the time being.

In the current development phase, SaaScada is focusing on acquiring customers from various branches of the financial industry as well as other sectors. According to SaaScada, initial discussions are taking place with companies from other industries, e.g. from the automotive industry (focus: leasing) and the hotel industry (focus: alternative payment options for guests).

SaaScada is currently concentrating on the UK and European markets. It is expected to expand into other markets as part of a future financing round.

In addition to the flexible architecture and data storage, SaaScada’s value proposition lies in the provision of the Product Configuration Engine, which promises customers a new approach to product delivery and pricing. This gives customers the opportunity to tailor their offerings to different target groups, select partners according to their needs, and offer the scalable provision of services.

SaaScada defines the domain capability (e.g. authorisations for card processing or ordering new or virtual cards) but provides this function (e.g. card processing) through partners. In the example of card processing, SaaScada is integrated into the authorisation flow. If an end customer makes a purchase online with a credit card, SaaScada receives a query from the card issuer/processor, decides whether sufficient funds are available based on a holistic view of the individual’s assets, and returns this information to the card issuer/processor.

The chart below shows the comprehensive flexible capability in the non-functional area combined with the highly focused functional support as a globally deployable integration platform.

Blockchain-like transaction log

For its core banking systems, SaaScada uses an immutable transaction ledger that relies on a Command Query Responsibility Segregation architecture to run commands and queries entirely separately. The command and query sides interact via the event processor.

Data model

The data can be accessed on the SaaScada portal via interfaces and the graphical user interface. Data formats comply with current standards and can be configured by the customer for data import and export. SaaScada can customise user interfaces at the customer’s request and provide individual data formats, for SQL databases for example, thus allowing data to be exchanged efficiently with other core or peripheral systems.

The data can be accessed on the SaaScada portal via interfaces and the graphical user interface. Data formats comply with current standards and can be configured by the customer for data import and export. SaaScada can customise user interfaces at the customer’s request and provide individual data formats, for SQL databases for example, thus allowing data to be exchanged efficiently with other core or peripheral systems.

Product configuration

Alongside transaction processing, SaaScada also differs fundamentally from other core banking systems in respect of product configuration in that it does not offer dedicated modules for payments, financing, investments, etc. Instead, SaaScada provides a single product API with a user interface that allows you to create a wide range of products.

This Product Configuration Engine offers the full spectrum of financial product-related features (e.g. charges, interest rates, cards, etc.), which can be applied to any product. To create a new product, therefore, the user must select the desired features. Once a new feature has been created, it is available for all products.

Services

SaaScada currently offers traditional banking products relating to payments and financing: accounts, payments, savings, and loans.

Each customer account consists of one or more ledgers, referred to as wallets. Wallets can be used to satisfy a wide range of use cases, including savings pots and budgeting (for household outgoings, holidays, etc.), FX and crypto, BNPL etc. Items can be held in different currencies without the bank having to execute trades in each individual network. Rather, SaaScada allows financial institutions to manage items internally and allocate funds within the platform without having to use the banking network.

SaaScada is not focussed on the fast-moving brokerage or day trading markets but does enable banks and fintechs to use the digital wallet capability to hold all kinds of assets, e.g. digital assets, or tokenised values. Third parties will continue to be responsible for custody. Additional products that have already been configured include securities accounts, money market and metal accounts, money market accounts, incentive-based savings, and savings schemes (securities, funds). SaaScada can integrate external data sources for reconciliation, e.g. holdings at correspondent banks or brokers.

Ability to deliver and ecosystem

In line with its strategic direction, SaaScada pursues structured partner management and strategic partnerships. The main partnerships at the present time are with technology providers and service providers (e.g. card providers). The SaaScada community is still being established, which is again due to the number of current customers. Eight evaluation or implementation projects are currently taking place with customers. SaaScada has substantial capacity for growth and integration and facilitates the structured involvement of customers in its further development.

Operability

SaaScada does not employ a code and configuration deployment model in its release approach. As a SaaS solution, all versions are fully backwards compatible and new features can be added over time as needed. It is run on Docker containers from Amazon Web Services (AWS), although from a purely technical point of view, SaaScada can also be operated on a private cloud or on prem.

Resilience is ensured by microservices, which provide additional or alternative instances in the event of container failure. The basic version does not offer external monitoring interfaces for SaaScada, but uptime is part of the SLA between the customer and SaaScada. SaaScada’s flexibility is also in evidence here: if necessary, the system can be opened to customers and performance can be monitored externally.

The user experience (UX) design is fully intuitive and supported by wizards, eliminating the need for user training.

Architecture

Inspired by other industries, SaaScada relies on a strongly cloud-based microservice architecture with a modern database model. Unlike established systems, SaaScada employs a noSQL database to provide information in near real time or to process particularly high data volumes. In contrast to relational databases, noSQL databases process or store information in values, data pairs or objects, for example.

In a first phase, standardised, defined interfaces are to be created for new SaaScada functionalities and, in a second step, these will be offered to customers via the company’s own portal. Customers are free to use the portal as a graphical interaction platform or to exchange information automatically over interfaces.

All transaction processing events are published in real time. Data is hosted in a customer-specific AWS account in local AWS data centres in Switzerland. In the current start-up phase, SaaScada only runs on AWS to reduce complexity, but the architecture would also accommodate other clouds or private data centres.

Security

Secure software development lifecycle and continuous security testing are fully implemented in SaaScada. Data projections could be used to anonymise data at all levels of the system. SaaScada does not intend to act as a system for recording customer data and observes best practices in relation to the GDPR and equivalent legislative frameworks. Data availability for employees of the bank or third-party providers (TPP) can be adjusted using role-based access rights.

All customers are given their own SaaScada environment and the same version, which means that each release is the same for everyone and there are no different versions for different customers. Outside of the core, other components can be used in the individual customer environment e.g., to generate individual data views.

SaaScada’s pricing model starts with a setup fee, which includes three integrations with other systems (e.g. banking, payments, cards). A basic monthly fee is also charged, which includes an account allowance. These SaaS fees come into play as soon as the system goes live. Pricing is based on the number of accounts per month and not the number of wallets within each account.

There are no extra fees for additional modules or functionalities. This differs from other core banking systems, which often charge an additional fee for additional modules (e.g. investments etc.). SaaScada’s business model envisages covering increasing complexity and costs through multiple modules under the SaaS approach. Its value proposition is to enable a much swifter return on investment by supporting the deployment of solutions in parallel with an existing core system. At the same time, they encourage their customers to expand their use of SaaScada with a pay-as-you-grow-per-account model, instead of having to buy more modules, add-ons, transaction fees and integrations.

The business model also applies when SaaScada is used by a bank to complement its existing core banking system.

The best-of-breed approach is founded on the conviction that core systems and architectures rely on microservices and that organisations will have a desire for flexible configuration in the future.

SaaScada sees itself as a core banking system or as an integration layer for existing core banking systems with additional service management elements (see fig. 1). Due to this positioning, it is essential for it to connect to different customer systems and components over interfaces that send data from or to third-party systems, e.g. CRM systems, products for AML or KYC checks, etc. Often, SaaScada is integrated in parallel with an existing core banking system to develop or expand service management capabilities.

SaaScada customisation options can accommodate banks’ typical product management and credit administration requirements. In the area of investments, SaaScada offers products such as bonds and integrates functions for real-time communication with peripheral systems for portfolio management. However, as previously indicated, the existing core banking system currently must be used for managing securities (e.g. master data management, corporate actions, etc.).

The orchestration of all additional services that SaaScada does not cover (e.g. AML, KYC, CRM, accounting, data warehouse, and so on) increases complexity for customers due to the integration requirements. SaaScada takes responsibility for all transaction-critical integrations (e.g. reconciliation), meaning that, if a customer’s third-party system changes something on the APIs, SaaScada will manage it.

SaaScada supports the core strategic elements described in previous articles as follows:

Open source:

SaaScada uses open API interfaces to provide data and functions to third-party systems. Due to the SaaScada architecture, third-party software, and components must be integrated to map regulatory requirements (e.g. PEP checks, AML screenings etc.).

Data:

SaaScada’s intention is that customers should manage their own data and not include information in their datasets that can be seen as master data records outside of their own system. Nevertheless, SaaScada supports open data integration, allowing customer data to be enriched with other information (e.g. third-party real estate data, CO₂ data, etc.) to facilitate product-related decision making. In the data projections, SaaScada structures external and internal data to enable meaningful queries.

Functions:

The SaaScada core enables the provision of basic banking services (payments, financing, and investments). Expanding the functional scope and connecting the necessary components requires significant provider management expertise on the part of the customer. This provider management complexity must be balanced against the added value of the flexible architecture.

Processes:

The transactional data storage approach and separation between the transaction and the respective item in the ledger requires customers to rethink their data processing (in respect of reporting intervals and the decisions made as a result, for example). Likely, this will also affect other processes that are supported by third-party software and components, especially if they do not follow the same data logic as SaaScada. On the other hand, real-time data from SaaScada on customer events offers opportunities for banks (e.g. demand-based fees for securities transactions).

SaaScada’s flexibility and customisation options allow customers to pursue a best-of-breed strategy by putting together an operating environment tailored to their individual requirements. For established banks, the use of SaaScada supports the flexible connection of third parties, with SaaScada becoming an integration layer for the existing core banking system. Event-driven data storage allows decisions to be made based on real-time data, which in turn opens new opportunities for customers. By positioning itself as a service management layer, SaaScada affords considerable freedom in the selection of providers and third-party systems.

For customers, the challenge will be to make the most of SaaScada’s decision-making scope in terms of partners and product design. It is highly likely that customers will need to develop additional IT capabilities, especially in respect of data storage or connecting third parties. Provider management skills are also required to fully leverage the potential of flexible service management.

For customers, the challenge will be to make the most of SaaScada’s decision-making scope in terms of partners and product design. It is highly likely that customers will need to develop additional IT capabilities, especially in respect of data storage or connecting third parties. Provider management skills are also required to fully leverage the potential of flexible service management.