Composition Overview

How FinFactory composes client-facing products from reusable primitives behind a unified product surface.

Source: docs/01_blueprint.md, docs/02_ecosystem_architecture.md

Core idea

FinFactory is not a single fintech application. It is a platform made of reusable financial primitives.

Each primitive is a bounded service with its own domain, API, database, events, operational rules, and compliance responsibilities. Products are composed by combining primitives through a unified product API and an orchestration layer.

Product composition example

A stored-value e-wallet can be composed from:

  • Identity and KYC
  • EMI wallet issuing
  • Ledger
  • QRPh payments
  • Fraud detection
  • Settlement and reconciliation
  • Unified product API
  • Product orchestration layer

The client product should not integrate with each primitive separately. Instead, FinFactory should expose one unified API for the composed product while the platform orchestrates the underlying primitives internally.

Unified Product API

The Unified Product API is the external-facing API layer exposed to a client product.

Its purpose is to hide primitive complexity and present a clean product-specific API.

For example, a stored-value wallet product should expose concepts such as:

  • Customers
  • Wallets
  • Balances
  • Cash-ins
  • Cash-outs
  • QR payments
  • Transfers
  • Transactions
  • Statements

The client should not need to know whether a request touches the KYC service, wallet issuing service, ledger service, QRPh service, or fraud service.

Product orchestration layer

The product orchestration layer coordinates workflows across primitives.

It owns:

  • Product templates
  • Workflow definitions
  • Tenant configuration
  • Feature flags
  • Product limits
  • Routing rules
  • Primitive activation
  • Policy enforcement
  • Cross-service transaction state

The orchestration layer determines which primitives are involved in a product and how they should interact.