Integrated Reinsurance & Finance Core

Company Overview

The client is a Jakarta-headquartered domestic reinsurance carrier founded in 1987, licensed for general and life reinsurance. It began as a captive reinsurer serving a large Indonesian insurance group, then expanded to serve cedants across the market—mirroring the growth of Indonesia’s insurance sector. The firm is widely regarded as one of the country’s big four domestic reinsurers and has long carried regional exposure across ASEAN, including early participation in ASEAN-level reinsurance cooperation frameworks.

For an institution of that scale, placement volume, treaty complexity, and regulatory-grade finance cannot stay in disconnected spreadsheets and ad hoc tools. The program replaced fragmented operations with one ecosystem: underwriting and contract logic on one side, billing, claims settlement, commissions, and the general ledger on the other, with a deliberate integration spine so both domains stay reconcilable and auditable.

Team & delivery

Work was delivered under my leadership as Lead Architect: one Product Owner, one System Analyst, one Scrum Master, and three tribes—frontend, backend, and QA. I coordinated with three project managers and those tribes to keep architecture consistent across Go, .NET, and the hybrid data layer.

Tech Stack

Features & modules

• Facultative reinsurance: end-to-end workflow from risk submission and underwriting through placement tracking, with state that must align to finance for premiums and adjustments.
• Treaty reinsurance: automation of long-term contract structures, retention and cession logic, and lifecycle operations that feed financial recognition over time.
• Life reinsurance: dedicated handling of life portfolios, mortality and premium mechanics, and reporting lines distinct from non-life facultative/treaty patterns.
• Finance module (.NET/MSSQL): centralized engine for premium billing, claim payments, commissions, and general ledger entries with audit-friendly posting rules.
• Cross-domain integration: explicit contracts so facultative, treaty, and life transactions propagate to finance in near real time without duplicate manual entry.
• Reporting and reconciliation: operational and finance views grounded in synchronized facts across relational cores, document stores, and the finance ledger.

Operations & data scale

• 500+ HTTP/API routes spanning user-facing modules, back-office workflows, and integration/event paths (order-of-magnitude footprint observed in production).
• 200+ relational tables across operational databases (PostgreSQL/MySQL) and the finance tier (MSSQL), before counting document collections in MongoDB used for treaty and policy artifacts.
• On the order of two million additional persisted rows per year as business volume grows—driving strict schema governance, indexing strategy, and archival thinking.
• Thousands of columns in aggregate across normalized schemas and finance structures; complexity is as much about cross-store mapping and referential discipline as about any single table.

Problem

Facultative, treaty, and life portfolios generated heavy operational throughput; finance needed the same events reflected quickly and correctly. Siloed channels and manual bridges produced latency, reconciliation drift, and audit exposure between underwriting and accounting—unacceptable for a top-tier domestic reinsurer serving many cedants and supervisors.

Approach

Defined a three-tier, best-of-breed polyglot architecture: Vue.js for the presentation layer; Go for high-concurrency reinsurance engines; .NET for the finance module with enterprise transaction semantics; PostgreSQL/MySQL for operational relational integrity; MongoDB for semi-structured treaty and policy artifacts; MSSQL dedicated to finance for ACID guarantees, auditing, and reporting. The integration plane (HTTP APIs and asynchronous messaging) was designed so reinsurance domain events reliably drive finance postings with bounded consistency targets.

System Architecture

• Presentation tier: Vue.js single-page experiences across facultative, treaty, life, and shared operations, optimized for reactive forms and large data grids.
• Application / service tier: Go microservices (or modular services) for reinsurance engines; .NET services for finance and corporate integration—each runtime chosen for concurrency, transaction style, and team topology.
• Data tier split by responsibility: PostgreSQL/MySQL hold operational transactions; MongoDB holds flexible document shapes for contracts; MSSQL isolates finance for ACID reporting and audit.
• Integration tier: synchronous APIs for interactive flows plus messaging where decoupling and retries matter; idempotency and outbox-style patterns at the architectural level to protect ledger integrity.

Methodology

• Governance: shared API catalog, versioning discipline, and integration ownership between reinsurance squads and the finance tribe.
• Delivery: PO/SA/SM plus three FE/BE/QA tribes, coordinated with multiple project managers so polyglot boundaries did not fragment design decisions.
• Data: canonical identifiers and mapping layers between operational SQL, document stores, and MSSQL finance to preserve a single reconcilable narrative for underwriters and accountants.

Outcome

Delivered a low-latency polyglot architecture bridging Go and .NET, automated reconciliation between reinsurance operations and accounting, and technical documentation for cross-platform APIs and hybrid relational/document schemas—at a scale where hundreds of tables and hundreds of HTTP routes must remain governable.

Engineering Challenges

• Challenge: Keeping underwriters and accountants on one coherent truth across MongoDB, relational SQL, and MSSQL. Solution: Strict data mapping, synchronization rules, and integration contracts between operational stores and the finance ledger, with explicit reconciliation checkpoints.
• Challenge: Maintaining consistency across Go reinsurance services and the .NET finance stack. Solution: Defined the integration boundary, event vocabulary, and API specifications so each placement or adjustment class maps to an auditable financial posting path.

Key Contributions

• Polyglot, low-latency reference architecture unifying Go reinsurance engines and the .NET finance ecosystem for a top-tier domestic reinsurer.
• Integrated automated reconciliation between reinsurance operations and accounting at multi-million-row annual growth.
• Technical documentation for cross-platform APIs and hybrid relational/document schemas under a 500+ route surface.

References

• General historical context on Indonesian domestic reinsurance carriers (including founding era, Jakarta HQ, general/life lines, and regional cooperation narratives) is summarized on Indonesian Wikipedia; articles there may be incomplete—treat as background, not regulatory fact.