Faster change,
with stronger control.
BX-CBP-based offerings reuse banking capabilities through components and APIs. Product composition is defined for each offering. Where microservices and containers are required, BX-CoCore can be evaluated as a separate alternative Main Product.
How the BX-CBP platform is built, layer by layer.
BX-CBP is a component-driven core banking platform built on the Adaptive Banking architecture: BX-PF, BX-RDF and BX-CBB form the reusable banking engine, BX-CBB its technical foundation, the Business Service Library the banking services, and BX-PF, BX-M or BX-CM and optionally BX-I sit around it. These composition rules apply to BX-CBP-based offerings; BADA, the Bankware Digital Payments Solution and the Bankware Supply Chain Finance Solution have their own Main Product and composition. Statements about BX-CoCore, the separate MSA and container-based core, say so.
BX-CBP platform architecture
From channels down: interface layer, service components, base components, then framework, data access and database. BX-CBB is the technical foundation; the Business Service Library is the pre-built banking services on it.
- ·BX-CBB: 11 foundation components exposing about 4,000 APIs, BX-CBP’s technical layer
- ·Business Service Library: pre-built services in 11 business domains (a different grouping from the 11 components)
- ·Service components for channels and downstream systems: customer, deposit, loan, payment, accounting, user portal, monitoring
- ·Base components: reusable capabilities service components are assembled from
- ·Five code layers: UI, service, domain, utility and data access
- ·BX-RDF: internal BX-CBB module and part of the banking engine, for business rules, organisation, calendar, operating conditions and permissions; not a product
Component-driven services and microservices
BX-CBP assembles banking services from BX-CBB components on one Java platform with inter-service calls inside the framework. For independently scalable containerised microservices, BX-CoCore, a separate product, can be evaluated as the alternative Main Product, subject to technical assessment; it is not a deployment option of BX-CBP.
- ·Banking services organised by business domain and assembled from reusable components
- ·Inter-service calls routed inside the framework, without external coordination for BX-CBP
- ·BX-CoCore: containerised microservices where MSA is required; ready to sell, no commercial reference yet
- ·BX-CM microservice support: service discovery, load balancing, compensating transactions, cross-service transaction coordinator
- ·Stated direction: one codebase for on-premise and cloud, toward BIAN v12 aligned domain-driven microservices
Product Factory
Products are assembled from templates in BX-PF, not fixed in the core, and distributed to core, channels and partners. A new product type within the supported templates is configured without a program change; requirements beyond them are scoped as Controlled Extension or Additional Development. BX-PF is a separate, required Technology Platform in every BX-CBP-based offering.
- ·Template-based product definition: condition group templates, condition templates and calculation unit templates
- ·Business staff configure supported rates, fees and product conditions in the Configurator, without writing new code
- ·Rate, fee and condition configuration with pre-launch, account-agnostic simulation
- ·Multi-channel deployment: selective distribution, change tracking and pre-release validation
- ·Multi-view classification: risk, compliance, seller, buyer and finance views
- ·Unified catalogue (competitor products, AI-assisted entry); unified fee management with what-if simulation
- ·Product lines: deposits, loans, cards, payments and settlement, service products, generic types (membership, points, merchant)
Parameterization
Frequently changing rules live as parameters outside program code, in what Bankware material calls the Configuration Center. Configuration is one of five kinds of delivery work, separate from Controlled Extension and Additional Development.
- ·Business rules, organisation, calendar, operating conditions and permissions (BX-RDF within BX-CBB)
- ·Financial product terms, rates and fees as product definitions (BX-PF)
- ·Maker-checker approval: single or multi-level, amount thresholds and timeout escalation
- ·Transaction restrictions by actor, customer, contract and channel
- ·Business-day and holiday calendar, numbering and sequence rules, common codes
- ·Organisation, employee and permission management with multi-dimension access control
- ·Notification through a unified API and multi-language content
Deployment environments and MSA containers
BX-CBP is built for on-premise and cloud deployment, in public or private cloud; supported infrastructure and product versions are confirmed for the target deployment. SaaS (BADA, the Bankware Supply Chain Finance Solution) is an operating model, not a synonym for cloud. Cloud-native describes only BX-CoCore’s MSA and container-based architecture.
- ·On-premise: infrastructure the bank controls, as at K-Bank (x86 and UNIX)
- ·Cloud: public or private
- ·Container platforms: Kubernetes and Docker, Amazon EKS, Alibaba ACK, alongside virtual machines
- ·Build and operations tooling: Jenkins, Terraform, ELK; registries GitLab, Nexus, Amazon ECR
- ·BX-CoCore (MSA, containers): benchmarked with IBM Japan on LinuxONE (s390x) vs x86, a technical validation, not a customer deployment
Open Banking
Core banking functions are exposed as APIs, so channels, partners and embedded-finance use cases call the same services. Which APIs open externally, and how secured, is decided in the bank’s Integration scope.
- ·Business Service Library APIs exposed to channels, partners and banking-as-a-service use cases
- ·Authentication, authorisation and encryption on exposed APIs (AES-256, SEED-256, ARIA-256, 3DES, TLS)
- ·Partner access to product definitions through BX-PF permissions by institution and user
- ·Payment networks, card schemes and regulators via BX-I or a third-party interface product
BX-I integration
BX-I is one configurable layer for multi-channel integration (MCA), enterprise application integration (EAI) and external financial interfaces. It is optional in BX-CBP-based offerings and replaceable by a third-party interface product.
- ·Tiers: external channel, flow processing, internal channel; flow layers: base, message, error
- ·Interface registration in the development environment; registered configuration drives execution
- ·Apache Camel routing engine with router pool; web administration for routing rules
- ·Asynchronous request and response handling for high-volume processing
- ·Protocol and message transformation, message encryption and decryption, scheduler and test simulator
- ·Apache Camel, Netty, Spring and Apache Kafka; runs on-premise or in cloud
BX-M framework
BX-M (on-premise) or BX-CM (cloud) is the Java development platform of BX-CBP-based offerings: one of the two is required in each, and Controlled Extension and Additional Development are built on it. Hot Deploy applies within the supported change scope and validated deployment procedures. Reference sites include K-Bank, Shinhan Bank and BC Card.
- ·Application framework on Spring with hierarchical transaction processing and inter-service calls
- ·BX Studio: Eclipse-based environment with bidirectional design-to-source linkage, specialised editors and testers
- ·Spring Batch based batch engine with parameter management, execution monitoring and real-time intervention
- ·Hot Deploy: update supported services while they remain running, with Pre-Deploy and Application Staging first
- ·Timeout and resource control, error-threshold transaction control, web-based log administration
- ·Template-based code generation, code inspection and impact analysis
- ·BX-CM: Spring Boot online runtime, microservice support, Netty-based BX Bridge adapter for existing systems
BX-CoCore: when your architecture
requires microservices and containers.
Where a bank requires an MSA and container-based architecture, BX-CoCore, a separate core re-architected as microservices in containers, can be evaluated as the alternative Main Product to BX-CBP, subject to a technical assessment of the offering; the difference is architecture, not deployment environment. The BX-CBP composition rules do not apply to it automatically. It is ready to sell with no commercial deployment yet; a benchmark with IBM Japan on IBM LinuxONE (s390x) against x86 is a technical validation, not a customer reference.
Discuss the Product Foundation.
Tell us about your institution and what you are evaluating.