REA Framework & Bank Ontology: A Complete Tutorial A tutorial on the REA (Resources, Events, Agents) framework applied to banking ontology covers McCarthy's 1982 model, OWL ontology building with Python and RDFLib, SPARQL queries, and AI/ML integration patterns. The tutorial explains how REA preserves economic reality over traditional accounting and maps to industry standards like FIBO and XBRL. REA Framework & Bank Ontology: A Complete Tutorial A hands-on tutorial on the REA Resources, Events, Agents framework applied to banking ontology — from McCarthy's 1982 origins to building a working OWL ontology with Python, RDFLib, SPARQL queries, and AI/ML integration patterns. Table of Contents REA Framework & Bank Ontology: A Complete Tutorial Level: Intermediate Time to complete: 60–90 minutes Prerequisites: Basic understanding of databases, some familiarity with Python or JSON; no prior ontology experience required Learning Objectives By the end of this tutorial you will be able to: - Explain the three REA primitives and how they relate to each other - Map real banking transactions onto the REA model - Read and write basic REA Turtle/OWL notation - Build a working REA ontology for a simple loan lifecycle using Python and RDFLib - Understand how REA connects to FIBO, XBRL, and modern AI/ML data pipelines in banking Table of Contents What is REA? The 1982 Idea That Never Got Old part-1 The Three Primitives — Resources, Events, Agents part-2 REA Relationships — How the Pieces Connect part-3 What Makes It an Ontology? part-4 Why Banks Use REA Ontology part-5 Tutorial: Build a Bank REA Ontology in Turtle part-6 Tutorial: Build the Same Ontology in Python with RDFLib part-7 Real-World Example: Modelling a Loan Lifecycle part-8 REA Meets FIBO — The Industry Standard Layer part-9 REA as a Foundation for AI/ML in Banking part-10 Exercises exercises Further Reading reading Part 1 — What is REA? The 1982 Idea That Never Got Old In 1982, William E. McCarthy, a professor at Michigan State University, published a paper titled “The REA Accounting Model: A Generalized Framework for Accounting Systems in a Shared Data Environment.” The core argument was simple and radical at the same time: traditional double-entry bookkeeping destroys information. When a bank records a debit of $10,000 to a loan receivable and a credit of $10,000 to cash, it captures the accounting result of a disbursement — but it throws away the economic reality underneath it: who requested the loan, what collateral was pledged, which officer approved it, what the disbursement event actually consisted of. You get the balance sheet entry; you lose the story. McCarthy’s REA model proposed recording the economic reality directly, in three kinds of things: ┌───────────────────────────────────────────┐ │ REA FRAMEWORK │ │ │ │ RESOURCE ←── EVENT ──→ RESOURCE │ │ │ │ │ AGENT s │ └───────────────────────────────────────────┘ Resource — something of economic value that is increased or decreased Event — an economic occurrence that changes the value of resources Agent — an individual or organization that participates in an event That’s the whole model. Three nouns, and the relationships between them. Everything in financial accounting — every ledger, every statement, every report — can be derived from instances of these three things. Why does this matter today, 40+ years later? Because every modern banking challenge — regulatory reporting, AI-driven decisioning, data interoperability between core systems — requires exactly what REA provides: a single, unambiguous semantic layer that describes what actually happened economically , not just what the accounting system recorded. Part 2 — The Three Primitives: Resources, Events, Agents 2.1 Resources A Resource is anything of economic value that a bank holds, lends, borrows, or exchanges. In the REA model, a resource has a quantity or value that can be increased or decreased by events. Banking resources — concrete examples: | Resource | Description | Key Attribute | |---|---|---| Cash | Physical or central bank deposits | Balance, currency | LoanReceivable | Amount owed by a borrower | Principal, rate, term | Deposit | Customer’s claim on the bank | Balance, rate type | SecurityPosition | Holdings of bonds, equities | Units, market value | CreditLine | Approved but undrawn credit | Limit, drawn amount | Collateral | Asset pledged against a loan | Type, appraised value | FeeReceivable | Earned but unpaid fees | Amount, due date | A critical point: a Resource in REA is not an account. A LoanReceivable account in the general ledger is a derived view of loan resource instances. The resource itself is the actual loan — its terms, its parties, its economic substance. 2.2 Events An Event is an economic occurrence — something that happened and changed the quantity or value of one or more resources. Events are the heart of the REA model. They are what gets recorded; everything else is computed from them. Banking events — concrete examples: | Event | Decrements | Increments | Description | |---|---|---|---| LoanDisbursement | Cash | LoanReceivable | Bank pays out loan principal | LoanRepayment | LoanReceivable | Cash | Borrower repays principal | InterestPayment | Cash borrower | InterestIncome | Borrower pays interest | DepositReceived | Cash | DepositLiability | Customer deposits funds | Withdrawal | DepositLiability | Cash | Customer withdraws funds | SecurityPurchase | Cash | SecurityPosition | Bank buys a bond | SecuritySale | SecurityPosition | Cash | Bank sells a bond | FeeCharge | FeeReceivable | FeeIncome | Bank charges a service fee | WireTransfer | DepositLiability sender | DepositLiability receiver | Funds move between accounts | Notice that every event has a duality : something is given up and something is received. This is the REA equivalent of double-entry — but instead of debits and credits, you have economic give and receive. 2.3 Agents An Agent is a person or organization that participates in an event — either as the provider giving up the resource or the receiver gaining it . Banking agents — concrete examples: | Agent | Role | Examples | |---|---|---| Customer | Borrower, depositor, investor | Retail client, SME, corporate | Bank | Lender, custodian, counterparty | The institution itself | Employee | Internal actor, authorizer | Loan officer, trader, teller | Counterparty | Trading party, correspondent | Another bank, broker-dealer | Regulator | Supervisory authority | OCC, Fed, FCA, ECB | ThirdParty | Service provider, guarantor | Insurer, credit bureau, servicer | In REA, agents are linked to events through participation relationships. A loan disbursement event has the bank participating as provider of cash and the customer participating as receiver. The same customer then participates as provider of repayments in subsequent loan repayment events. Part 3 — REA Relationships: How the Pieces Connect The primitives alone aren’t enough. REA defines four core relationship types that wire everything together. 3.1 Duality The most important relationship in REA. Every economic exchange involves at least two events: one that decrements a resource and one that increments a resource. These paired events are connected by a duality relationship. LoanDisbursement ←──────── duality ────────→ LoanRepayment Bank gives cash Bank receives cash back DepositReceived ←──────── duality ────────→ Withdrawal Bank receives cash Bank gives cash back The duality relationship is what makes REA accountable. Every give must have a corresponding receive, either now spot transaction or in the future credit transaction via commitments — see 3.4 . 3.2 Participation Participation links an Agent to an Event, specifying their role. Customer ──── participates-in ──── LoanRepayment ──── participates-in ──── Bank as provider as receiver Participation can carry additional attributes: the timestamp when the agent authorized the event, their role designation, the delegation chain, and whether they are the primary or secondary participant. For compliance purposes, participation is often the most auditable part of the model — it captures who did what. 3.3 Stockflow Stockflow links an Event to the Resources it affects. It distinguishes whether the event increments or decrements the resource quantity. LoanDisbursement ──── decrements ──── CashResource LoanDisbursement ──── increments ──── LoanReceivableResource The name “stockflow” comes from the distinction between stocks resources, which have a balance at a point in time and flows events, which change that balance over time . Think of it exactly like physics: water level in a tank stock is determined by the flow of water in and out. 3.4 Commitment REA Extension McCarthy later extended the model with Commitments — planned or promised economic events that haven’t happened yet. In banking, this is enormously useful. COMMITMENT ──── fulfilled-by ──── EVENT │ ├── reserves Resource notional └── involves Agent as obligated party Banking uses of commitments: Loan approval commits the bank to future disbursement Credit line agreement commits the bank to lend up to a limit Repayment schedule commits the borrower to future payments Trading order commits a counterparty to a future securities exchange Commitments let you model the lifecycle of a banking product — from application through to final settlement — without conflating promises with economic facts. Part 4 — What Makes It an Ontology? The word “ontology” comes from philosophy the study of what exists , but in computer science it means something specific: a formal, machine-readable vocabulary of concepts and their relationships in a domain . An REA framework becomes an REA ontology when you express it in a formal language — typically OWL Web Ontology Language using RDF Resource Description Framework syntax — that allows: Inference : a reasoner can derive new facts from existing ones Interoperability : any system that understands OWL can consume the data Constraint checking : the ontology can validate that data conforms to the model Querying : SPARQL can retrieve facts across the entire graph The basic building blocks in OWL/RDF: | OWL Term | REA Meaning | Example | |---|---|---| owl:Class | A type of REA primitive | rea:Resource , rea:Event | owl:ObjectProperty | A relationship | rea:duality , rea:participatesIn | owl:DatatypeProperty | A scalar attribute | rea:quantity , rea:date | owl:Individual | A specific instance | loan:Disbursement 2026 001 | rdfs:subClassOf | Specialization | bank:LoanReceivable subClassOf rea:Resource | When you hear “banking ontology” — whether it’s the FIBO Financial Industry Business Ontology , XBRL taxonomies, or a bank’s internal knowledge graph — REA often sits underneath as the economic substrate, even if not explicitly named. Part 5 — Why Banks Use REA Ontology 5.1 Regulatory Reporting Regulatory reporting Basel III, FINREP, COREP, FR Y-9C requires banks to slice the same economic reality many different ways: by risk weight, by maturity bucket, by counterparty type, by product. If the underlying data is stored as accounting entries, each new regulatory view requires a custom ETL pipeline. If the underlying data is stored as REA events, the regulatory view is just a different query over the same graph. 5.2 Interoperability Between Core Systems A large bank typically has dozens of core systems: loan origination, core banking, trade finance, treasury, collateral management, risk engines. Each has its own data model. REA ontology provides a canonical semantic layer that all systems can map to — so a loan in the origination system and a loan receivable in the core banking system are understood as representations of the same rea:Resource instance. 5.3 Audit Trails and Compliance REA naturally produces audit trails. Every economic event is a first-class record, with participating agents, timestamps, and links to the resources affected. This maps directly to what regulators require: who authorized what, when, and what changed as a result. 5.4 AI and ML Data Pipelines This is the most exciting modern application. LLMs and ML models trained on or querying banking data need to understand what entities mean , not just what columns exist. An REA ontology tells an AI agent that a LoanRepayment event is semantically related to a LoanDisbursement event through a duality relationship — enabling a credit risk agent to reason about the full lifecycle of a loan rather than treating each transaction row as an isolated fact. 5.5 FIBO Alignment The Financial Industry Business Ontology FIBO , maintained by the Object Management Group OMG , is the closest thing banking has to an industry-standard ontology. FIBO’s transaction and event layers are heavily influenced by REA. If your bank is building FIBO-compliant data models, understanding REA is the prerequisite. Part 6 — Tutorial: Build a Bank REA Ontology in Turtle Turtle .ttl is the most readable syntax for RDF/OWL. Let’s build a minimal but complete REA ontology for a bank loan product, step by step. Step 1: Set Up Prefixes Every Turtle file starts with namespace declarations. Think of these as imports. @prefix rdf: