Unified data infrastructure
GitHub Let's talk

Fintech

Money movement and its operational record, together.

A financial product is a ledger plus a set of decisions, and both have to be correct while the product changes weekly.

See Transactional Systems All of Financial Services

A ledger that behaves while the product changes weekly.

The story

A ledger that behaves while the product changes weekly.

Where it starts

Ledger entries and balances

Double-entry postings, holds and derived balances. It is the first of 4 workloads running in Fintech.

The question it raises

Correctness under change

Ledger postings stay transactional while product-specific fields live as documents in the same layer.

Why one question is hard

From Onboard to Report

Fintech data moves through 4 stages — Onboard → Move money → Watch → Report. The shapes in play are SQL, JSON / documents, Time series, Graph, and answering one question means reading across all of them.

What PLOMID contributes

A fintech needs a ledger that behaves and a schema that can move. These are the parts that allow both.

The environment

Ledgers, balances, product events and the relationships behind them.

Ledgers and balances need transactional correctness. Products change shape constantly, which makes documents a practical way to hold configuration and per-product fields. PLOMID keeps the ledger, the flexible product data and the decision signals in one layer, so a new product does not require a new store.

Where the data goes to work

Questions money asks repeatedly.

Each one reads records, and where it must, the relationships between them — from the same layer, not an extract.

Correctness under change

Ledger postings stay transactional while product-specific fields live as documents in the same layer.

  • JSON / documents
  • SQL

One source for balances

Derived balances and posted entries come from the same system, so they cannot drift apart.

  • SQL

Signals with context

A decision reads the account, its relationships and its history in one request.

  • Time series
  • Graph

Smaller operational surface

Fewer systems means fewer places where a copy of the ledger can quietly exist.

  • SQL
The data journey

How fintech data reaches one layer.

Walk the path the data takes, from the environment that produces it to the questions it answers. Select a station, or a shape, to read each step.

A ledger that behaves while the product changes weekly.

Environment

The product

A financial product whose configuration keeps changing shape.

JSON / documents

Data models in play

The shapes, in one layer.

4 shapes carry this domain. Choose a stage to read the operation, or a shape to see every stage that handles it.

PLOMID · Fintech onboard · move money · watch · report Select a stage
Stage

Onboard

Identity, agreements and product configuration

JSON / documents · SQL

Workload map Fintech workload map. Every shape on it is a surface of the layer, and each stage names the part of the operation it carries.
  • SQL Records, keys and joins
  • JSON / documents Documents and nested objects
  • Time series Measurements and events in time order
  • Graph Relationships and traversal
One environment · many workloads

What runs against fintech data.

4 workload families over one set of shapes. Choose one to see what it moves and where it lands.

Double-entry postings, holds and derived balances.

  • Planned once against the layer, not once per store
  • Read beside the records it shares a key with
  • Persisted under one storage contract
Workload architecture

From posting to traversal.

Records first, relationships where the question needs them — every path a request can take through this data.

Fintech · workload architecture
Workloads

What runs against this data.

  • Ledger entries and balances
  • Product configuration
  • Behaviour signals
  • Relationships
Data models

The shapes those workloads read and write.

  • SQL
  • JSON / documents
  • Time series
  • Graph
The layer

One path from a request to the data it names.

  • Planning Predicates narrow the work before it runs
  • Execution Records, fields and windows answered together
  • Transactions Readers and writers do not block each other
Surfaces

How the work reaches the layer.

  • SQL surface The query language the layer is documented in
  • Applications Services and jobs writing and reading as they run
  • Analytics & AI clients The same layer, the same access path
Deployment & residency

Where this data is allowed to run.

Small teams operate the system themselves, which makes a single system to run a practical requirement rather than a preference.

Deployment, residency and control
What you build next

Transactional Systems

Application records with consistent reads and writes while reports run against them.

If Correctness under change is your question, start here.

See Transactional Systems Every solution
Next

Where to go next

Solutions The workload answers this industry leans on, with their models and status. Platform The data models in the product today, and the ones extending the layer. Architecture How a request is planned, executed and persisted once it reaches the layer.