How a Regional Bank Built a Service‑Reuse Middle Platform to Cut Product Launch Time by 60%

Definition of a Middle Platform

A middle platform is an enterprise‑level service‑reuse capability created through changes in operating model, organization, and IT architecture. Its four attributes are:

Enterprise‑level : distinguishes true platform capabilities from simple service‑oriented applications.

Capability : the core objects the platform provides.

Reuse : enables shared use of capabilities across front‑end business lines.

Platform : the delivery form of these capabilities.

Why Banks Need a Middle Platform

Traditional bank IT landscapes contain many siloed systems (e.g., >140 in Hunan Sanxiang Bank), leading to:

Repeated development of core capabilities such as customer and account management.

Complex integration when launching new products.

Tight coupling of product, account, transaction, and accounting modules.

Architectures that are difficult to refactor.

These problems extend product‑to‑market cycles to three months or more, far longer than the sub‑month cycles of fintech firms. The primary driver for middle‑platform projects in banks is therefore technological efficiency rather than direct business demand.

Bank Business Middle‑Platform Architecture

The platform is organized into six core “centers,” each exposing a standard set of interfaces that decouple front‑end channels from back‑end product systems.

User Center : Manages customer lifecycle, multi‑channel login (username, phone, email, biometrics, third‑party), unified view of assets and behavior, and contract management for four user types (anonymous, registered, verified, account‑holding).

Product Center : Stores product catalog, attributes, promotions, and fees; synchronizes product data between core systems and channels; supports channel‑based filtering for personalized product lists.

Accounting Center : Provides real‑time and batch accounting, separating customer‑visible accounting from internal bank‑wide accounting; supports rule configuration, real‑time posting, and batch posting.

Account Center : Defines a unified account model (basic info, balance, freeze, contracts, media binding) and implements three separation concepts—product vs. account, medium vs. account, and account vs. account—to enable flexible product‑account mapping and multi‑media support.

Payment Center : Consolidates all payment functions (debit, credit, third‑party, asset‑based) and integrates with the accounting engine via a unified payment order model.

Transaction (Order) Center : Introduces an e‑commerce‑style order model capturing order header, line items, fee adjustments, and multiple payment instruments, supporting cash and non‑cash settlements (points, vouchers, product‑based payment).

New products can be launched by implementing only the six standard interfaces, eliminating the need for each channel to integrate directly with every product system.

Implementation Experience (Sanxiang Bank)

Project scope: 22 systems built, of which six constitute the core business middle platform. Timeline: 3 months design, 2 months procurement, 3 months development, 1 month testing/rollout. Key success factors:

IT‑led project initiation : external assessment, high‑level interviews, board approval.

Strict development standards : multiple technical specifications enforced across vendors.

Autonomous high‑level design : bank owned functional specs and interface definitions; vendors only implemented to those designs.

Bypass architecture : legacy systems remained operational while middle‑platform services were added; adapters reused existing systems; products migrated incrementally.

Outcome: average new‑product implementation cycle reduced by 60 %; the six core middle‑platform systems were built with fewer than ten outsourced developers.

Technical Details

Real‑time data pipeline: OGG (Oracle GoldenGate) → Kafka → Flink → Oracle/HBase.

No distributed transactions; consistency achieved via business‑level compensation (exception handling and reversal).

Primary open‑source framework: Alibaba SOFA distributed framework; other vendor‑specific middleware used but not pure open‑source stacks.

Future extensions: Rights Center and Marketing Center.

Key Q&A Highlights

Middle platform emphasizes service reuse rather than pure SOA; it abstracts capabilities into standardized models.

System‑wide unique identifiers include three levels: unified transaction ID, system‑level ID, and interface‑level ID.

Bypass architecture minimizes risk: legacy interfaces stay unchanged, middle platform provides a small set of standardized APIs (e.g., a single generic accounting API).

Account Center abstracts accounts into a unified model with contract‑based relationships, supporting fund‑flow contracts, virtual sub‑accounts, aggregation contracts, and group accounts.

Payment Center unifies debit, credit, third‑party, and asset‑based payments, handling both cash and non‑cash settlement types.

Transaction Center’s order model supports multi‑product, multi‑payment‑instrument orders, enabling “one‑click” product purchase across channels.