use casesintermediate

From FIBO to a Financial Services Operating Graph

How banks and financial institutions extend the FIBO ontology into an enterprise operating graph, enforce policy on AI agents with SHACL and SHACL-AF, and record every decision as W3C PROV-O provenance.

8 min read
Updated 10/13/2026
TrustGraph Team
#Financial Services#Banking#FIBO#Ontology#SHACL#SHACL-AF#PROV-O#Agent Governance#Operating Graph

Financial institutions are putting AI agents to work on payments, onboarding, lending operations, reconciliation and client servicing. The agents are capable. The problem is that a capable agent with API credentials can act regardless of contract, mandate, authority or evidence, and "the model decided" is not an answer a risk committee, an auditor or a regulator will accept.

This guide describes how to give agents the context and the limits they need, using open standards end to end:

  1. FIBO to describe financial services in a shared, formal vocabulary
  2. An enterprise operating graph that extends FIBO to describe how your firm actually operates
  3. SHACL and SHACL-AF to express policy as machine-checkable rules that TrustGraph evaluates before an agent acts
  4. PROV-O to record every decision, with its evidence and policy version, as queryable provenance

1. Start from a domain standard: FIBO

The Financial Industry Business Ontology (FIBO) is an open OWL ontology maintained by the EDM Council. It formally defines the concepts that financial services runs on, including:

  • Legal entities and parties: organizations, legal persons, and the roles parties play
  • Agreements and contracts: their parties, terms and obligations
  • Financial instruments and products: securities, loans, derivatives and their characteristics
  • Business and corporate structure: ownership and control relationships

Starting from FIBO, rather than inventing a schema, has three practical benefits. Definitions are reviewed by the industry, so "counterparty" or "contract" means the same thing to your agents, your data teams and your partners. The ontology is expressed in W3C standards (RDF and OWL), so it is portable across any compliant tool. And it already encodes the relationships that matter for control, which is exactly what a policy check needs to traverse.

2. Extend FIBO into your operating graph

FIBO describes the industry. Your firm needs a graph of itself: its legal entities, products, approved suppliers, mandates, accounts, delegated authorities, approval chains and the policies that govern them. That is the enterprise operating graph.

You build it by extending FIBO with your own classes and properties, never forking it. Your concepts specialize FIBO's, so every FIBO-aware query and tool still understands them:

# Illustrative. FIBO prefixes abbreviated; acme: is your enterprise namespace.
acme:ApprovedSupplier  rdfs:subClassOf  fibo-be-le-lp:LegalPerson ;
    rdfs:label "Approved supplier" ;
    rdfs:comment "A supplier that has passed onboarding and due diligence." .

acme:SupplierAgreement rdfs:subClassOf  fibo-fnd-agr-ctr:Contract ;
    rdfs:label "Supplier agreement" .

acme:ProposedPayment   a owl:Class ;
    rdfs:label "Proposed payment" ;
    rdfs:comment "A payment an agent proposes to execute, pending policy evaluation." .

acme:delegatedLimit    a owl:DatatypeProperty ;
    rdfs:label "Delegated limit" ;
    rdfs:comment "The maximum amount an actor may approve without escalation." .

TrustGraph then populates the operating graph from the documents and systems where this knowledge already lives: contracts, supplier files, policy manuals, authority matrices, procedure documents. Its ontology-guided extraction (Ontology RAG) produces facts that conform to your FIBO-based ontology, so a supplier, a contract and an approval limit land in the graph as exactly those things, linked to their sources.

The result captures the essence of how the firm operates: who it does business with, under which agreements, who may authorize what, and which rules apply. It is the shared context that both people and agents reason over.

3. Express policy as SHACL, enforce it before execution

Most AI guardrails filter what a model says. Financial controls are about what an agent does. TrustGraph sits between the agent and execution: every proposed action is resolved against the operating graph and evaluated against explicit policy before it runs.

SHACL (the W3C Shapes Constraint Language) expresses those policies as shapes the graph must satisfy. A supplier payment, for example:

# Illustrative policy shape: what a valid supplier payment looks like.
acme:SupplierPaymentPolicy a sh:NodeShape ;
    sh:targetClass acme:ProposedPayment ;
    sh:property [
        sh:path acme:payee ;
        sh:class acme:ApprovedSupplier ;
        sh:message "Payee must be an approved supplier." ] ;
    sh:property [
        sh:path acme:coveredBy ;
        sh:minCount 1 ;
        sh:class acme:SupplierAgreement ;
        sh:message "Payment must be covered by a valid supplier agreement." ] ;
    sh:property [
        sh:path acme:beneficiaryAccount ;
        sh:class acme:VerifiedAccount ;
        sh:message "Beneficiary account must be verified." ] .

SHACL Advanced Features (SHACL-AF) add rules that derive new facts from the graph. That is how judgement-dependent policy, like delegated authority, becomes explicit and testable:

# Illustrative SHACL-AF rule: flag payments above the initiator's delegated limit.
acme:DelegatedAuthorityRule a sh:NodeShape ;
    sh:targetClass acme:ProposedPayment ;
    sh:rule [
        a sh:SPARQLRule ;
        sh:construct """
            CONSTRUCT { $this acme:requiresApproval true . }
            WHERE {
                $this acme:amount ?amount ;
                      acme:initiatedBy ?actor .
                ?actor acme:delegatedLimit ?limit .
                FILTER (?amount > ?limit)
            }
        """ ] .

The outcome maps directly onto TrustGraph's three decisions:

Evaluation resultDecisionWhat happens
All shapes conform, no approval derivedALLOWThe integration executes the payment
A rule derives an approval requirement, or evidence is missingPAUSEThe runtime fetches fresher evidence or requests approval, then re-evaluates
A constraint is violated, such as an unapproved payee or no covering contractDENYThe agent cannot execute the action

Because the rules live in the graph, not in prompts, they are versioned, reviewable and testable like any other control. The LLM proposes; the policy decides.

4. Record every decision with PROV-O

A control is only as good as the evidence that it ran. TrustGraph records each decision as W3C PROV-O provenance: which agent proposed which action, the facts it was evaluated against, the exact policy version, the outcome and when it happened.

# Illustrative decision record.
acme:evaluation-4471 a prov:Activity ;
    prov:used acme:payment-4471, acme:agreement-C118, acme:policy-v14 ;
    prov:wasAssociatedWith acme:accounts-payable-agent ;
    prov:startedAtTime "2026-10-13T09:41:07Z"^^xsd:dateTime .

acme:decision-4471 a prov:Entity, acme:PolicyDecision ;
    prov:wasGeneratedBy acme:evaluation-4471 ;
    acme:outcome acme:Allow .

Since the record is itself linked data in the graph, it can be queried like any other knowledge: show every payment allowed under policy v14 last quarter, which decisions relied on this agreement, which agent actions were paused for approval and by whom were they released. An outcome can be reproduced and explained, not reconstructed after the fact.

What this gives a financial institution

  • Defensible agents. Every agent action is checked against the firm's own definitions, authorities and policies before execution, and the reason for each outcome is recorded.
  • Shared meaning. FIBO gives business, data, risk and technology teams the same vocabulary, and the operating graph applies it to the firm.
  • Controls as artifacts. Policies are explicit SHACL, versioned and testable, rather than buried in code or prompts.
  • Audit-ready by construction. PROV-O decision records answer who, what, why, under which policy and with what evidence.
  • No lock-in. FIBO, RDF, OWL, SHACL and PROV-O are open standards, and TrustGraph is open source. The operating graph belongs to the firm and can run in any cloud or on-prem.

Frequently asked questions

What is FIBO?

FIBO, the Financial Industry Business Ontology, is an open, standard OWL ontology maintained by the EDM Council that defines the concepts used in financial services, such as legal entities, parties and roles, contracts, financial instruments, loans and securities, along with the relationships between them.

What is an enterprise operating graph?

An operating graph is a knowledge graph of how one specific organization actually works: its entities, products, counterparties, contracts, accounts, authorities, processes and policies. Built on FIBO and extended with the firm's own concepts, it gives AI agents and people a shared, formally defined picture of the business.

How does SHACL-AF enforce policy on AI agents?

SHACL constraints describe what a valid action looks like, such as a payment that must be covered by a contract with an approved supplier. SHACL Advanced Features add rules that derive new facts, such as flagging that an amount exceeds the agent's delegated authority. Evaluated against the operating graph before execution, constraint violations deny an action, derived approval requirements pause it, and conforming actions are allowed.

Why record agent decisions with PROV-O?

PROV-O is the W3C standard for provenance. Recording each decision as PROV-O captures the proposed action, the agent, the evidence and the exact policy version used, as queryable linked data. That gives auditors, risk teams and regulators a reproducible account of why an agent was allowed, paused or denied.

Next steps