Financial Services OS
Every position is recorded. The exposure is assembled by hand.
- Core banking
- Accounts, balances, transactions
- Loan origination
- Applications, decisions, terms
- Risk systems
- Exposure, provisioning, limits
- KYC and AML
- Identity, screening, alerts
- Wealth platforms
- Portfolios, mandates, performance
- Regulatory reporting
- Submissions, breaches, filings
Plate data
- Industry
- Financial services
- Status
- Reference architecture
- Agents
- 06
- Layers
- 07
The architecture applied, published in full, ready to be built on.
Four questions those systems cannot answer.
- Why did default risk move in this segment?
- Which exposures breach limits under next quarter's conditions?
- Which alerts are worth an analyst's day?
- Which system carries the action, and who approves it under the risk framework?
The industry, in miniature.
Customer, account, loan, portfolio, exposure, limit, alert, obligation, counterparty, filing.
Ontology fragment · financial services
ENTITY exposure
RELATIONSHIP loan -> held_by -> counterparty
EVENT limit_breach
METRIC expected_loss
RULE credit_decision_authority (enforcement: approval)
DECISION alert_prioritisation
ACTION case_createCredit and compliance decisions carry delegated authority. The ontology models that authority, so an agent can never exceed the mandate of the role it serves.
Each one introduced by the question it answers.
Banking
What changed in this segment's behaviour this month?
Wealth
Which portfolios have drifted from their mandate?
Risk
Which exposures breach limits under next quarter's conditions?
Underwriting
What is the case for and against this credit, in the bank's own policy language?
Compliance
Which AML alerts are worth an analyst's day, and why?
Customer
Why did this relationship's value change, and what is the retention risk?
What the Industry Pack contains.
- Ontology
- Exposures, limits, obligations and alerts.
- Reference workflows
- Credit review, limit monitoring, alert triage and portfolio review.
- Agent templates
- Six agents with authority limits pre declared.
- Connectors
- Core banking, origination, risk, KYC and AML systems.
- Evaluations
- Built from historical decisions, including declined cases.
The expectation here is explainability, not just accuracy.
Every recommendation carries the reasoning that produced it and the policy it was tested against.
requires_human_approval: credit_decisions customer_communications regulatory_filings limit_changes alert_closureAlert closure sits on the list deliberately. An agent may rank and explain. Closing a case remains a human act.
Read next.
- Pharma OS
- The one with a product behind it. Same band order, plus deployment.
- Healthcare OS
- The same seven bands, applied to a different industry.
- Real Estate OS
- The same seven bands, applied to a different industry.
- Manufacturing OS
- The same seven bands, applied to a different industry.
- The Super Brain spec
- The twelve required services and the three conformance levels.
- Industry Ontology Schema
- How the ontology fragment on this page is declared.
One architecture. Twenty pages. Same document.
This is the architecture applied, not a product yet.
Published in full and ready to be built on. If your risk or compliance function is drowning in alerts rather than data, that is the place to start.
A conversation, not a demo script. We ask what your systems of record are, what they cannot answer, and which decisions actually matter. If an Industry OS is not the right answer for you, we will say so.