Traditionally, banks and financial service providers relied on massive monolithic core systems to facilitate transactions, accounts and other financial services. Recently, coreless banking has come into play, which then split systems into smaller microservices. These services—typically hosted in the cloud and communicate through APIs—are much easier to scale, maintain and update compared with a traditional monolith.
IBM Cloud for Financial Services® has recently collaborated with several other BIAN partners to release BIAN Coreless 3.0, a new version for a coreless banking framework. IBM Cloud® platform and services facilitated the collaboration between partners on various components of the solution. This includes building the continuous delivery and continuous integration (CD/CD) pipelines for microservices, scanning for security, testing and deploying the application on IBM Cloud for Financial Services with security and compliance.
The BIAN coreless application implements a scenario where a customer has an existing relationship and accounts with a bank and is looking for other products and services offered by a financial provider that is partnering with the bank. The customer can grant consent to the financial provider to gain access to the customer’s profile data including accounts, product and bank transactions.
Based on those data, the financial provider can then offer products and services that are suited for the customer’s interests and start the onboarding process upon the acceptance. All the interaction with the customer happens within the banking application, thereby providing a seamless user experience.
IBM Cloud for Financial Services developed three toolchains to manage those components: Continuous Integration for building, testing and scanning individual microservices; Continuous Deployment for deploying the entire application to a secure landing zone; and Continuous Compliance for ensuring that the components remain secure and vulnerability-free even while deployed. These toolchains work with multi-component applications.
The solution is hosted on the Red Hat® OpenShift Container Platform on VPC landing zone. This is one of the reference architectures for IBM Cloud for Financial Services and is compliant with the associated control framework. The security features of this architecture include bastion hosts and separated VPCs for management and workload clusters. In addition, the key management and encryption are handled through Hyper Protect Crypto Services with dedicated FIPS 140-2 Level 4 HSMs - “Keep Your Own Key”.
The goal for each partners’ component was the same: reduce complexity in building code and to simplify the onboarding of microservices into the coreless systems. Typically, a partner would host their source code in a GitHub repository. Due to the setup of the toolchains, no build artifacts had to be hosted in application repositories. Instead, there is a separate, private repository specific for build artifacts that is common to all applications, regardless of the programming language used.
This allowed us to maintain the common build approach, so every microservice went through the same testing and build stages. The only difference in approach was specific tooling, such as testing frameworks.
While the BIAN solution has microservices that are developed by multiple partners, IBM was responsible for building the container images from the source code, deploying OpenShift® resources and maintaining the infrastructure components. Each service’s source code was hosted on GitHub and maintained by the relevant author.
The toolchain enforces best practices, adding several restrictions to the GitHub repo of each team. This includes branch protection, so that code cannot be committed directly to the main branch of a repository without going through the build process first. Other examples of restrictions on a repository include mandatory reviews of pull requests—and that the PR pipeline successfully runs when a pull request is opened—before a merge is allowed.
When a partner creates a pull request, the CI toolchain will automatically run a PR pipeline, which is a subset of the main CI toolchain steps. These steps check for vulnerabilities and run tests before allowing a merge to the main branch. The toolchain used is IBM Cloud Toolchain, which specifically uses the best practices for secure and compliance pipeline.
The CI pipeline is responsible for building the images from the source code that the partners provide, along with IBM-developed images. It also runs unit tests, dynamic scans and API tests if necessary. Vulnerability scans are run against both the code, the resulting docker image and any dependencies listed. A generated software bill of materials or SBOM asserts the origin of the software and dependencies. The docker image is signed for provenance and stored in a private image registry. An inventory repository stores details of the image, such as tag, signature and pipeline ID for use by a CD pipeline. The CI pipeline can build multiple images in parallel, but this inventory contains the details for all components that are part of the BIAN solution.
Before the CD pipeline can run, the inventory must be “promoted” as it is the single source of truth for what component versions are running in which environment. Environments are represented as branches in the inventory repository, so the promotion pipeline creates a pull request to allow a newer version of the BIAN application to be deployed.
Once this is complete, the CD pipeline creates a change request for the deployment. This includes all change details, an impact assessment, rollback plans and the SBOMs from each component. The image signatures are verified using a GPG public key and the application components are deployed to a secure landing zone by the CD pipeline. Probes conduct readiness checks, and the application is rolled back to the previous state if issues are detected. This process can be repeated for testing, staging and production environments as many times as is necessary.
The CC pipeline runs the same unit tests and vulnerability scans as the CI pipeline. However, it is run on a schedule—usually nightly—and has a different purpose. It aims to keep already deployed code up to date and free from vulnerability. If a new vulnerability is reported by a vulnerability database such as SNYK or CVE, the CC pipeline allows the user to know if their code is affected. In relatively simple cases, the CC pipeline can even automatically submit a PR rectifying the issue.
Throughout all pipelines, evidence of each task is gathered and stored in an immutable COS bucket. This creates an audit trail that can be used during a compliance audit. Any change request created for a deployment also includes this evidence.
Because all components of the BIAN Coreless initiative going through the same pipeline checks, they all adhere to a common set of security controls. The IBM Cloud Security and Compliance Center (SCC) enforces this. The SCC allows a user to automate the evaluation of the current posture of their deployed infrastructure and applications, define profiles and rules to check against and increase compliance visibility across an entire organization.
With IBM Cloud for Financial Services and IBM Cloud DevSecOps, you can easily develop, deploy and maintain a multi-component financial application, even when those components are developed by different vendors. Using a common set of tools to build, test and deploy the components of BIAN v3, IBM boosts security across code, images, or deployment.