Unified data infrastructure
GitHub Let's talk

Banking

Positions, ledgers and risk on one timeline.

Banking data is records with a relationship structure layered on top, and every useful question, exposure, anomaly, almost-fraud, starts with that structure.

See Transactional Systems All of Financial Services

A posting that stays exact while the network around it is traversed.

The story

A posting that stays exact while the network around it is traversed.

Where it starts

Transactions and balances

Postings, holds, balances and statements as records. It is the first of 4 workloads running in Banking.

The question it raises

Exposure across a network

Counterparty exposure is a traversal over relationships that already live beside the transactions, not a reconstruction from joins.

Why one question is hard

From Originate to Report

Banking data moves through 5 stages — Originate → Transact → Monitor → Investigate → Report. The shapes in play are SQL, Graph, Time series, JSON / documents, and answering one question means reading across all of them.

What PLOMID contributes

Records must stay exact while the analytical questions get harder. These are the parts that carry both.

The environment

Accounts, transactions, counterparties and the relationships between them.

Transactions and balances are structured records with strict consistency requirements. The interesting questions concern parties, accounts, devices and counterparties, which are relationships. PLOMID keeps transactional records and their relationships in one layer, so a risk question does not begin with an extract into a graph tool.

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.

Exposure across a network

Counterparty exposure is a traversal over relationships that already live beside the transactions, not a reconstruction from joins.

  • SQL
  • JSON / documents

Anomaly with context

A behavioural signal is read against the account’s history, its relationships and its channel in a single request.

  • SQL
  • Time series

Consistent books under load

Snapshot reads let reporting run while postings continue, with one definition of the current state.

  • Graph
  • Time series

Case evidence

Documents, decisions and the transactions they concern stay queryable together.

  • JSON / documents
  • SQL
The data journey

How banking 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 posting that stays exact while the network around it is traversed.

Environment

The account

Accounts and parties whose balances must always be right.

SQL

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 · Banking originate · transact · monitor · investigate · report Select a stage
Stage

Originate

Applications, onboarding and party records

SQL · JSON / documents

Workload map Banking 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
  • Graph Relationships and traversal
  • Time series Measurements and events in time order
  • JSON / documents Documents and nested objects
One environment · many workloads

What runs against banking data.

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

Postings, holds, balances and statements as records.

  • 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.

Banking · workload architecture
Workloads

What runs against this data.

  • Transactions and balances
  • Signals over transactions
  • Party relationships
  • Case and policy documents
Data models

The shapes those workloads read and write.

  • SQL
  • Graph
  • Time series
  • JSON / documents
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.

Core records stay inside the institution; the fabric for placement and residency is direction, and it is stated as such.

Deployment, residency and control
What you build next

Transactional Systems

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

If Exposure across a network 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.