Context Ontology for Financial Services: Give Banking AI the Meaning Behind Every Transaction

Transaction Ontology
Explainable AI in Finance
Agentic AI in Banking
Context Ontology Accelerator
AWS Context

Context ontology for financial services is how Mactores gives AI the meaning behind a transaction: one model linking each payment, transfer and trade to the accounts, parties, beneficial owners, merchants, counterparties and products involved, along with the rules that decide what is normal, what is suspicious and who may see it. AML, fraud, disputes and payments agents check that model before they act, so every alert they raise or close can be traced from the answer back to the data and the rule. Your risk and compliance owners agree the definitions with us. We deploy the model into your AWS environment on the Context Ontology Accelerator today, move it to AWS Context once AWS makes that service available, and fix the fee and go-live date in the SOW before the first session.

Ask an AML agent whether four cash deposits of $9,400 to $9,800, made at three branches over five days, look like structuring. It finds the deposits in the core ledger, the customers in the CRM and last quarter's alerts in case management. Then it clears them, because on paper they belong to four unrelated businesses. Only the beneficial ownership records show that one person controls all four, and only the product terms reveal that one account is a cash-intensive business with its own thresholds. The agent saw every transaction. It never saw what tied them together, and an examiner reading its rationale would spot the gap in seconds.

Bring one alert your agent closed and shouldn't have

Share the alert, the accounts behind it and the agent's rationale. In one working session we trace what it missed and size a first release, with a date attached.

Book a scoping call →

0audit incidents while a branded-payments leader cut over to its PCI DSS-aligned AWS platform
94%of Mactores engagements finished on or ahead of the date we committed to
30 daysof satisfaction guarantee on every Mactores engagement
90 daysin which production defects found after acceptance are repaired free
2008the year Mactores delivered its first AWS customer work

AWS Premier Tier Services Partner
AWS Agentic AI Specialization
AWS Data and Analytics Consulting Competency

Why Does Your AI See a Transaction but Not What It Means?

Because a transaction record carries amounts, dates and codes, not relationships. Whether a payment is routine, suspicious or disputable depends on who owns the accounts, what the merchant really is, which product rules apply and what happened before. Those facts sit in different systems under different names. A context ontology links them, so agents reason about meaning, not rows.

Banks already hold every fact an agent needs. The trouble is where each fact lives. Core banking knows an account holder, the CRM knows a party under another ID, and the beneficial ownership file knows the person behind both. The card platform records a descriptor such as SQ *BLUEBTL 4471, the acquirer knows a merchant ID, and the merchant category code still says coffee shop after the business has started moving money for others. One customer is a borrower in lending, a policyholder in insurance and an investor in wealth. Read one system at a time, the data supports a confident and wrong conclusion.

Regulators and bank leaders are arriving at the same worry from different directions:

79%

of financial regulators surveyed rate explainability as critical or important, and 70% of regulators and firms alike rank hallucinations among their top AI risks, per the Cambridge Centre for Alternative Finance (April 2026, 628 organizations, 151 jurisdictions).

63%

of US banking leaders name data readiness and access as their biggest AI challenge, even though 39% already run AI agents, according to KPMG's Q2 2026 AI Quarterly Pulse of 204 leaders.

Up to 80%

higher agentic AI accuracy by 2027 for organizations that put semantics into AI-ready data, Gartner predicts, adding that regulators will demand greater semantic transparency.

Underneath those numbers are a handful of failures that show up at almost every institution we work with:

What goes wrong	Why	What the ontology adds
AML alerts close as unrelated when one person sits behind several accounts	Ownership and control data live outside the transaction systems	Parties, accounts and beneficial owners linked, so the agent sees the network behind each alert
Fraud and dispute agents misjudge merchants	Descriptors, merchant IDs and category codes disagree, and merchants change what they sell	One merchant identity carrying its descriptors, acquirer IDs and category history
Two agents report different volumes or exposure for the same client	Each system counts its own way: by account, by legal entity or by household	One governed definition per figure, rolled up through LEI parent links where entities are involved
Dispute answers quote the wrong deadline	Regulation E, Regulation Z and card network timelines depend on a product and channel the agent can't see	Product, channel and the governing rule linked to each transaction
Alert rationales fall apart in model validation or an exam	Nothing records which data, definitions and rules led to a conclusion	Every conclusion stored with the data it read, the rules it applied and the ontology release in force

The pressure is specific and dated. Nacha's new fraud monitoring rules took effect in two phases this year, on 20 March and 19 June 2026, requiring ODFIs, RDFIs and many originators to run risk-based processes that identify ACH entries initiated by fraud. Instant payments on RTP and FedNow leave no recall window, so the context has to be present before release, not after. The open question is not whether agents reach these desks but whether they arrive able to explain themselves.

What Goes Into a Transaction Ontology: Accounts, Parties, Merchants, Counterparties and Rules?

A transaction ontology holds each transaction and everything that gives it meaning: the accounts on both sides, the parties and beneficial owners behind them, the merchant or counterparty, the product and channel, and the rules that apply. Mactores ties every local identifier to one shared record and writes monitoring, dispute and access rules as checks agents run.

We size the first release by the questions your investigators, fraud analysts and payments staff ask most, not by the size of the data estate. Ten to 20 of those questions, each with an owner and an answer everyone already accepts, set the boundaries of the model: the entities it needs, the links between them and the rules it enforces. When the release is finished, those same questions prove it works.

Entity	What the ontology records	Where it lives today
Transaction	Amount, currency, time, channel, direction and status, linked to both sides and the product	Core ledger, card authorization and clearing records, payment hub messages
Account	Product, owners, signatories, limits, status and the ledger it posts to	Core banking, card management, loan servicing
Party	Individuals and legal entities, with KYC status, risk rating and LEI where one exists	CRM, onboarding and KYC platforms, customer master
Beneficial owner and control	Who owns or controls each entity, and through which chain of companies	Beneficial ownership records, KYC case notes, LEI relationship data
Merchant	One merchant identity behind its descriptors, merchant IDs and category codes, with history	Acquirer and processor data, card network files, enrichment feeds
Counterparty	The other side of a wire, ACH entry, trade or claim, resolved to a known party where possible	Payment messages, ISO 20022 fields, trade capture
Product and channel	The terms that change what a transaction means: card, ACH, wire, RTP, FedNow, branch or mobile	Product catalog, pricing engine, channel systems
Alert, case and dispute	Monitoring alerts, investigations and disputes, with outcomes, linked to the transactions behind them	Transaction monitoring, case management, dispute platforms
Rule	Monitoring thresholds, dispute timelines, sanctions logic and entitlement rules	Policies, procedures, network rulebooks, compliance manuals

What the first release delivers:

Your transaction ontology, live in your AWS environment and matched to the questions your owners approved
Party and account resolution across core banking, CRM, card and KYC identifiers, using match logic your data governance team signed off
One merchant identity per business, with descriptors, merchant IDs and category history attached
Governed definitions for the figures in scope, such as alert volumes, dispute rates or exposure, reconciled to the report of record
Monitoring, dispute and access rules written as checks, each with an accountable owner
A test set of questions with known outcomes, run again whenever anything changes, along with runbooks and trained stewards

Drafted by agents

Draft classes and relationships pulled from core banking, card, payments and case management schemas
Likely matches between customer, party and beneficial owner records, each scored
Merchant clusters built from descriptors, merchant IDs and category codes
Draft rules read from AML procedures, dispute playbooks and product terms
A regression run on every change

Decided by your risk owners and our FDEs

Which record wins when the CRM and core banking disagree about a customer
What counts as a related party for monitoring purposes
Which dispute timeline applies to each product and channel
Who may see that a SAR was filed, which the law keeps confidential
When an agent's rationale is good enough to show an examiner

Agents handle the volume and people handle the calls that carry liability. That is how Mactores runs every program, and the accelerator is designed the same way: AWS says it cuts ontology drafting from months to days. In a bank, the time saved goes to the sessions that matter most, where the BSA officer, the head of fraud and the payments lead agree on what a related party is.

Where Does a Rules Engine or Customer Master Stop and the Ontology Take Over?

Most institutions already run the first three. The ontology connects them and supplies the meaning they leave out.

Capability	Monitoring rules engine	Customer master	Semantic layer	Context ontology
Scores transactions against scenarios and thresholds	Yes	No	No	Supplies the context scenarios lack
Resolves one customer across systems	No	Yes	No	Links that result to accounts, owners and merchants
Holds governed metric definitions	No	No	Yes	Yes, with owners and version history
Knows who controls whom and which merchants are related	Rarely	Partly	No	Yes
Holds dispute, sanctions and entitlement rules agents check	Its own scenarios only	No	No	Yes
Explains an answer from source data to rule	Alert reason codes	No	Query lineage	A full trace, ready for review

What Does Explainable AI in Finance Look Like When Agents Answer From a Transaction Ontology?

Explainable AI in finance means each agent answer arrives with its reasons: the data it read, the definitions it used and the rules it applied. With a transaction ontology underneath, agents can say which accounts share an owner with an alerted entity, which deadline governs a dispute and why a payment was held, and show the path.

AI in AML and fraud work usually comes first, because they carry the heaviest regulatory weight and the most wasted investigator time. Disputes and payments operations follow on the same model once parties, accounts and merchants are resolved.

Question	Data it pulls together	What the model settles
Which customers onboarded in the last 90 days share a beneficial owner with an entity under an open sanctions alert?	Onboarding, KYC, beneficial ownership, sanctions screening	Ownership chains across individuals and legal entities
Do these cash deposits across branches add up to possible structuring once related accounts are grouped?	Core ledger, branch systems, CRM, beneficial ownership	Which accounts count as related, and over what window
Is this disputed card charge covered by Regulation E or Regulation Z, and when must we resolve it?	Card platform, product catalog, dispute system	Product type, channel and the timeline that applies
Which merchants in our acquiring portfolio changed category or descriptor in the last 30 days while volume spiked?	Acquirer data, merchant onboarding, clearing files	One merchant identity across descriptors, IDs and category history
Which outbound wires this week went to counterparties linked to a customer we exited last year?	Payment hub, ISO 20022 messages, exit records	Counterparty resolution against known parties
How many incoming ACH credits did our fraud processes flag this month, by originator?	ACH receipt files, fraud monitoring, case outcomes	One governed definition of a flagged entry, matching what the fraud team reports

Credit concentration, reserving and suitability questions use the same model once parties and products are settled, which is why many banks begin with AML and payments and extend into lending and wealth later. The data foundation beneath all of it, from lineage to regulatory reporting, comes from our financial services data modernization practice, so the ontology sits on data your examiners already trust.

How Does a Transaction Ontology Help an Agent Explain an AML Alert an Examiner Can Retrace?

It gives the agent a path to follow and a record to keep. On the Context Ontology Accelerator, the agent resolves the alerted parties, walks ownership and counterparty links, applies the approved scenario rules and stores each step. AWS plans to carry those ontologies into AWS Context, its managed service announced in June 2026, which has no launch date yet.

AWS made the accelerator generally available on 31 July 2026 as Apache 2.0 open source. It uses Amazon Neptune, Amazon OpenSearch Serverless and Amazon Bedrock inside your account, as AWS's launch note describes, and it is self-managed: no financial ontologies ship with it, and AWS Support does not cover it. For a bank, that makes it a component in your own technology and third-party risk inventory, owned and patched like any other.

How Does One AML Alert Resolve, Step by Step?

Take the alert from the top of this page: four cash deposits just under $10,000 at three branches. The agent works it in this order.

Governed figures first. Totals the bank has already defined, such as cash volume per party over a rolling ten days, come straight from approved definitions, with no language model involved.
Relationship query next. To find who sits behind the four accounts, the agent queries the graph with SPARQL. The graph is virtual, so core banking, CRM and beneficial ownership tables are read where they already sit.
Document reasoning last. When the answer turns on written material, for example KYC notes describing the business or an earlier investigation narrative, the agent reads those documents subject to the same entitlements.

The investigator receives one rationale: the parties involved, the ownership link that connects them, the scenario rule that applies and the threshold it crossed, each tied to its source. If the alert becomes a suspicious activity report, which generally has to be filed within 30 days of initial detection, that trace gives the narrative its spine.

How Do Scan, Model and Serve Work on Banking Data?

Scan. Agents connect to the systems the first questions depend on, typically core banking, card and payment hubs, CRM and KYC platforms, case management, and documents such as AML procedures and dispute playbooks. Metadata is enriched and likely matches are flagged for review.
Model. Investigators, fraud analysts and payments specialists review the draft. Approved concepts are written as W3C OWL classes, monitoring and dispute rules become SHACL shapes, and R2RML mappings point each class at its source tables.
Serve. Agents query the result through the accelerator's MCP server or its SPARQL endpoint, and every query passes the same entitlement checks before any data comes back.

Which Financial Standards Ground the Ontology?

The accelerator brings no financial content of its own, so grounding comes from your models and from standards like these:

Standard	Gives the ontology	Our use
FIBO (Financial Industry Business Ontology)	OWL definitions for parties, accounts, contracts, loans and securities, published as an OMG standard	The backbone for parties and products; a CRM customer maps to a FIBO party
GLEIF Legal Entity Identifier data	Global identifiers for legal entities, with Level 2 data on direct and ultimate parents	Ownership rollups for exposure, sanctions and related-party questions
ISO 20022	The message model behind Fedwire (since July 2025), cross-border SWIFT payments and US instant payment schemes	Counterparty, purpose and remittance fields mapped into the ontology
ISO 18245 merchant category codes	The standard list of merchant categories used across card networks	Category history per merchant, so a change in what a business sells becomes visible
ACORD	Insurance data standards for policies, claims and parties	Translated into OWL for insurers, scoped to the first questions

Is It Worth Waiting for AWS Context?

Not for most banks. AWS intends to manage user-defined ontologies inside AWS Context and says accelerator-built ontologies can be brought across, but by early November 2026 it had named no preview or general availability date. Meanwhile, the work that takes longest is organizational: compliance, fraud and payments agreeing on what a related party, a disputed transaction and an active merchant mean. Those decisions, and the W3C files that hold them, carry over unchanged.

Which Phases Does a Financial Services Ontology Engagement Run Through, and Who Signs Each One?

Five phases, each ending in a signed exit: frame the questions, resolve parties and sources, agree meaning and rules with risk and compliance owners, test against known outcomes and entitlements, then go live in stages. Sessions are planned around month-end close, quarter-end reporting and exam windows, because the people who own definitions are busiest then.

We run the same delivery model as every Mactores program, fitted to a bank's calendar. Nothing touches a production monitoring or dispute workflow during a quarter-end close or an open examination, and model risk and compliance reviewers see the design before they see any results.

Phase 01
Frame the questions
What happens
The first 10 to 20 AML, fraud, dispute and payments questions are chosen and ordered, with an owner, source list and settled answer for each, and the platform and production date are fixed
Owner
Shared
Signed exit: Signed questions, data access terms and SOW
Phase 02
Resolve parties and sources
What happens
Agents scan core banking, card, payment and case data, and party, account, beneficial owner and merchant matches go to data owners for review
Owner
Agents and FDEs
Signed exit: Matching rules and source map approved
Phase 03
Agree meaning and rules
What happens
Compliance, fraud and payments leads settle definitions, monitoring and dispute rules become checks, and entitlements are designed with information security
Owner
FDEs and your experts
Signed exit: Owner-approved definitions, rules and entitlement design
Phase 04
Test against known outcomes
What happens
Agents answer questions whose outcomes are already settled, such as closed cases and resolved disputes, and every role is checked against its entitlements, refusals included
Owner
Agents and FDEs
Signed exit: Validation evidence accepted by risk owners
Phase 05
Go live in stages
What happens
Workflows move onto the ontology one by one under parallel running, alerting is switched on, and your stewards and on-call team take ownership
Owner
Shared
Signed exit: Customer-signed acceptance

Checks every agent clears before it touches live alerts or disputes:

Each in-scope term has one approved definition and an accountable steward
Parties, accounts and merchants resolve to single identities, with unresolved cases listed
Answers to known-outcome questions meet the pass mark set in phase one
Governed figures tie to the report of record, or each gap is explained and signed
Entitlement tests pass for every role, including refusals for SAR-related data and information barriers
Every answer stores its sources, rule results, entitlement decision and ontology version
The accelerator is logged in your technology and third-party risk inventory, with an exit plan
The release is pinned and the upgrade route documented
Cost ceilings are set for each environment
Named owners on your side hold the runbook and the pager

When phase one closes, the SOW binds scope, fee and production date together. A slip Mactores causes costs you nothing. Delays that begin on your side, such as a stalled data access approval or a reviewer who misses a phase exit, are billed hourly at the rate the SOW states. Our commitment covers the remaining terms.

What Has Mactores Shipped on Regulated Financial Data?

Three regulated financial programs: a real-time MBS pricing platform whose lineage, from raw signal to trading decision, is captured as it runs and aligned to FFIEC, SEC and FINRA expectations; a branded-payments leader's PCI DSS-aligned platform, cut over with zero audit incidents; and Tilia's payments platform, made more secure and more efficient at once.

MBS pricing · Capital markets

Real-time pricing that records its own lineage

The desk priced mortgage-backed securities in overnight batches, trading on the previous day's signals, and every earlier plan to price in real time had stalled once lineage and audit tasks swallowed the money set aside for it. Mactores built a real-time pricing platform on AWS in which every signal, model call and trading decision is traced while the system operates, so evidence for FFIEC, SEC and FINRA reviewers comes from the platform itself. FDEs owned the architecture, the desk cutover and the case put to regulators.

Read the MBS pricing story

Branded payments leader · Payments

A payments platform modernized on the third attempt

Two earlier modernization efforts stalled before cutover, because discovery used up the money a regulated payments cutover needs for risk management. Agents mapped dependencies and generated tests at scale, while FDEs sequenced the cutover by risk and kept a fallback plan ready. The platform moved to cloud-native AWS, aligned with PCI DSS, without a single audit incident during cutover.

Read the branded payments story

Tilia · Payments

Security and efficiency fixed in one engagement

Tilia's transaction platform was exposed on security and costly to run, and two earlier partners said fixing one meant giving ground on the other. Mactores studied the platform's security design and the way its operational data moved, in parallel, and FDEs designed a single target architecture that improved both, with PCI DSS-aligned controls and evidence produced during validation.

Read the Tilia story

None of these was an ontology project. Each one shows the discipline a transaction ontology depends on: lineage captured as decisions happen, controls proven during cutover and evidence an examiner can follow without a guide. More programs are on our stories page.

With SR 11-7 Gone and Agents Outside SR 26-2, How Do You Show an Examiner Why an Agent Answered?

By making the explanation part of the system. SR 26-2 replaced SR 11-7 in April 2026 and leaves generative and agentic AI to each bank's own governance, so the controls have to be designed in. The ontology records which data, definitions, rules and entitlement checks produced every answer, versioned, so an examiner can retrace any conclusion.

On 17 April 2026 the Federal Reserve, OCC and FDIC issued SR 26-2, superseding SR 11-7 and SR 21-8, the 2021 statement on models in BSA/AML systems. A footnote places generative and agentic AI models outside its scope and says a bank's own risk management and governance should determine the controls for anything the guidance does not cover. AI model risk management for statistical and non-generative models continues under the new guidance. For agents, the bank writes its own rules. FINRA's 2026 oversight report makes a similar point for broker-dealers, noting that autonomous agents may need new oversight, such as tracking their actions and restricting their system access.

Entitlements on every path. Who may see which accounts, cases and SAR-related information is enforced whichever way an agent queries, documents included. On the accelerator, enforcement comes from Cedar authorization and a SQL firewall, working together with your IAM roles and Lake Formation permissions.
Human decisions where liability sits. Agents can triage, assemble and draft. Closing an alert, filing a SAR, denying a dispute or blocking a payment stays with a named person.
Versioned meaning. Definitions and rules change only through steward approval, and known-outcome questions rerun before each release.
Retraceable answers. Each answer is stored with the data read, the definitions and rules applied, the entitlement decision and the ontology version, so it can be replayed long after the fact.

This is AI agent governance in practice: rules an agent reads at the moment it answers, rather than policies written for people and hoped for in software. The table maps the requirements most institutions face to where the ontology helps.

Requirement	What examiners and auditors expect	How the ontology supports it
SR 26-2 (Federal Reserve, OCC, FDIC)	Model risk management for statistical and non-generative AI models, with generative and agentic AI left to each bank's governance	Inventory entries for scoring components, and documented, tested controls for agents
BSA/AML and SAR rules	Suspicious activity reports filed on time, with a narrative that explains the activity	Rationale traces that give investigators the who, what and why in one place
Regulation E and Regulation Z	Error and billing-dispute investigations completed within set timelines, with provisional credit where required	Timelines encoded per product and channel, with governed metrics on cases resolved in time
Nacha fraud monitoring rules (2026)	Risk-based processes to identify ACH entries initiated by fraud, reviewed at least once a year	Originator, receiver and entry history linked, so monitoring and the annual review share one view
Regulation B adverse action	Specific principal reasons when credit is denied, including when models inform the decision	Reasons traced to the data and rules behind each decision
FINRA and SEC supervision	Oversight of AI tools, with agent actions tracked and system access restricted	Entitlements per agent and a log of every action
EU AI Act and DORA (EU operations)	High-risk obligations for credit scoring and life and health insurance pricing from 2 December 2027, plus ICT risk and third-party oversight	Documentation and logging built in, and the self-managed accelerator recorded in the ICT register with an exit plan

What Can an Examiner Ask, and Where Does the Answer Come From?

Examiner question	Source of the answer
Why was this alert closed without escalation?	The stored rationale: parties resolved, links followed, scenario rule and threshold
Which definition of a related party did the agent use in June?	The definition history and steward approvals for that term
Could a payments agent have seen information about a SAR?	Role-level entitlement test results and the query log
Were last quarter's Regulation E investigations completed on time?	The governed timeliness metric, by product and channel
Which ontology release produced this figure in the board report?	Release history linked to the answer trace

Which Banking, Payments, Insurance and Capital Markets Teams Need Transaction Context First?

Teams whose decisions depend on relationships no single system holds. Banks start with AML and fraud, where related parties and merchants decide outcomes. Payments companies start with disputes and fraud monitoring. Insurers start with claims and fraud referrals, and capital markets with surveillance and counterparty questions. Each first release goes after the costliest misread.

Banks and credit unions

AML and fraud lead. The ontology ties each account to its owners, signatories and beneficial owners, so structuring, mule networks and related-party patterns show up as connections rather than coincidences. Agentic AI in banking starts paying back here, because triage agents can gather the evidence an investigator would otherwise assemble by hand. Larger banks extend the same model to commercial exposure and credit concentration through LEI parent links. Investigators keep every decision to close or escalate. Financial services at Mactores

Payments and fintech

Disputes and fraud monitoring lead. One merchant identity carries its descriptors, merchant IDs and category history, and each transaction links to the Regulation E, Regulation Z or card network timeline that governs it. ACH programs gain a single view of originators and entries for Nacha's fraud monitoring rules, and instant payments on RTP and FedNow get their context before funds move. AI in payments, from chargeback automation to fraud screening, becomes safer when each case carries the right rule. See our payments and banking work

Insurance

Claims and fraud referrals lead. Policies, coverages, claimants, providers and repair networks link through ACORD-based classes translated into OWL, and every claim ties to the policy in force on the date of loss. Agentic AI in insurance can then flag a referral with the relationships behind it, such as one repair shop recurring across unrelated claims. EU insurers also prepare for life and health pricing becoming high-risk under the AI Act from December 2027. Insurance and financial services at Mactores

Capital markets and wealth

Surveillance and counterparty questions lead. Issuers, obligors and counterparties resolve through LEI data, positions link to instruments and desks, and information barriers keep private-side data away from public-side agents. Wealth teams use the same model to measure concentration per household rather than per account, across held-away assets where data allows. Every answer an agent gives a compliance officer arrives with the trade, the party and the rule behind it, ready for review. Explore our financial services practice

Fintech lenders, broker-dealers and payment processors usually start from one of these four patterns and adapt it to their own products.

How Is the Engagement Priced, and What Does the Accelerator Cost to Run on AWS?

A first release takes 8 to 12 weeks and covers 10 to 20 questions and a few source systems. The fee turns on the number of questions, systems and legal entities in scope, how far party and merchant data disagree, the volume of rules to encode and the strictness of entitlements. Mactores fixes fee and date when phase one ends.

Pricing note. A transaction ontology has no list price. The work scales with your estate: the number of systems holding customer data, the legal entities and products in scope and the rules that govern access. The accelerator itself is licence-free. Use the drivers below to frame a budget; the SOW you sign carries the binding numbers.

What drives cost	Why
Questions in scope	Each adds classes, links, rules and tests
Source systems and legal entities	Multiple cores, card processors and subsidiaries multiply the mappings
Party and merchant data quality	Duplicate customers and messy descriptors need matching and owner review
Rules and procedures	AML scenarios, dispute timelines and product terms must be encoded and approved
Entitlements and barriers	SAR confidentiality, information barriers and regional data rules add policy design and testing
Platform	Running the self-managed accelerator inside a regulated bank adds hardening, risk inventory work and on-call planning

Run cost. In production you pay AWS for the graph database, the search collection and model invocations. The cheapest answers are the ones that never reach a model: figures such as alert volumes or dispute rates resolve from governed definitions, and they are asked most often. Idle development environments shut down overnight, and finance sees a cost estimate per workflow before launch.

Which Explainable AI in Finance Terms Should Risk Leaders Know?

Context ontology: The governed description of your business that AI agents consult before answering: what exists, how it connects, what each term means and which rules hold.
Transaction ontology: A context ontology focused on transactions and everything that gives them meaning: accounts, parties, owners, merchants, counterparties, products and rules.
Explainable AI (XAI): AI whose outputs come with reasons a person can check, such as the data, definitions and rules behind each answer.
Beneficial owner: The individual who ultimately owns or controls a legal entity, often behind several layers of companies.
Legal Entity Identifier (LEI): A 20-character global identifier for legal entities, with Level 2 data showing direct and ultimate parents.
FIBO: The Financial Industry Business Ontology, a standard written in OWL for financial concepts such as parties, accounts, contracts and securities.
Merchant category code (MCC): A four-digit code under ISO 18245 that classifies the kind of business a card merchant runs.
Transaction enrichment: Adding meaning to raw transaction records, such as the real merchant name, category and location behind a descriptor.
Structuring: Splitting cash transactions into amounts below a reporting threshold to avoid it, which is itself a crime.
Suspicious activity report (SAR): A report a financial institution files with FinCEN when it detects activity that may involve money laundering or other crimes.
Governed metric: A figure, such as dispute rate or alert volume, that has a single signed-off formula and an accountable owner, so every report and agent computes it identically.
SR 26-2: The April 2026 interagency guidance on model risk management that replaced SR 11-7 and places generative and agentic AI outside its scope.
Information barrier: A control that keeps confidential information on one side of a firm, such as private-side deal data, away from people or agents on the other.
Model Context Protocol (MCP): The open protocol agents use to reach external systems; the ontology is one of those systems.
FDE: A Mactores specialist who works inside your risk, compliance and data teams from scoping through go-live, leads the definition sessions and is answerable for the go-live commitment.

How Can Mactores Help You Out?

Every route in comes with a fixed price and a committed date. If agents already triage alerts or disputes but staff redo the work, we start by reviewing their answers. If the questions are clear, we build a first-release transaction ontology. If core, card and KYC data still sit in silos, the data foundation comes first.

Mactores has delivered on AWS since 2008, often for institutions where an examiner reads the architecture before the results: payments platforms cut over without an audit incident, pricing systems that keep their own lineage. That background shapes how we build context. Every definition gets an owner and every rule gets a test, SAR-related data is walled off before any agent can ask about it, and go-lives stay clear of quarter-end close.

Your situation	Starting point	Outcome
Agents already triage alerts or disputes, but analysts redo the work	Alert and dispute answer review	The missing context behind each wrong answer, ranked, and a first-release scope with a date
The questions are known; reliable answers are not	First-release transaction ontology	Agents answering from a live ontology that your stewards maintain
Core, card, payments and KYC data remain siloed	Financial services data modernization	A governed data foundation on AWS, with lineage your examiners can follow

For the cross-industry view, including how we choose between platforms, see our context ontology services. In banking, the payoff compounds quickly: once parties, owners and merchants are resolved for AML, the dispute desk, payments operations and credit risk can all ask their own questions of the same model, and each new release costs less than the one before because the hardest matching work is already signed off. Mactores also connects the ontology to agents you already run, through MCP, so existing tools gain context without being rebuilt.

Where the agents are not built yet, our AI agent development services create them on top of this model, with the same signed phase exits. The division of duties is simple: the ontology says what a related party or a reversible payment is, and the agents choose the next step within limits your compliance team signs. Ownership is simple too. The ontology, mappings, rules and tests sit in your AWS account in open W3C formats, readable by other tools, and nothing about them depends on Mactores staying involved after handover.

On credentials: AWS Premier Tier Services Partner, the AWS Agentic AI Specialization and the Data and Analytics Consulting Competency, all listed with the rest on our AWS partnership page.

Which Questions Do Risk and Compliance Leaders Ask Before Starting?

What is context ontology for financial services?

It is a model of how your institution's customers, accounts, owners, merchants, counterparties, products and rules relate, which AI agents consult whenever they answer. It links data across core banking, card and payment systems, CRM, KYC and case management, and it carries the rules for monitoring, disputes and access, so agents interpret a transaction the way your investigators do.

What does explainable AI in finance mean for AI agents?

It means a person who wasn't present can check an agent's answer: which data it read, which definitions and rules it applied, which entitlement check it passed and which version of the model was live. A transaction ontology produces that record by design, and it is the record model validators, auditors and examiners ask to see.

How are AI agents used in banking today?

The most common uses are AML alert triage, fraud case preparation, card dispute handling, payments exception work and onboarding checks. Agents gather and assemble information across systems, while investigators and operations staff make the decisions that carry regulatory or customer impact. A transaction ontology keeps the agents' reasoning consistent and open to review.

Does SR 26-2 apply to AI agents?

No. SR 26-2 expressly places generative and agentic AI models outside its scope and tells banks to set governance and controls for them through their own risk management. Statistical and non-generative AI models stay within it. Banks still need documented controls, testing and evidence for agents, and the ontology supplies much of that evidence.

How do you secure AI agents in banking?

Start with entitlements the agent cannot bypass. Each agent gets its own identity and role, policies in the ontology decide which accounts, cases and documents it can reach, SAR-related information and information barriers are enforced on every query path, and anything that moves money or closes a case needs a person's approval. Every query is logged.

What is a semantic ontology in banking?

It is a formal model of banking concepts and how they relate, written in a standard such as OWL so software can reason over it. FIBO is the best-known example. A bank's own ontology usually extends FIBO with its products, rules and identifiers, and that extended model is what its agents query.

Is AWS Context available, and should banks wait for it?

Not yet. AWS unveiled AWS Context in June 2026 and, as of early November 2026, still had not said when customers could use it. Waiting buys a bank little. AWS indicates that ontologies made with the accelerator can move into AWS Context later, and the slowest part, agreeing definitions across compliance, fraud and payments, has to be done whichever platform holds them.

Is the Context Ontology Accelerator suitable for a regulated bank?

Yes, with the right operating model. It is open-source code you run in your own account, without AWS Support, so it belongs in your technology and third-party risk inventory with an owner, a pinned release, an upgrade path and an exit plan. Mactores can run it for you on a managed support basis, or hand it to your platform team after training.

Can the ontology use FIBO and LEI data?

Yes. FIBO provides OWL definitions for parties, accounts, contracts and securities, and GLEIF's LEI data adds legal entity identities and parent relationships. We import what your first questions need, extend it with your products and rules, and translate standards that aren't in OWL, such as ACORD for insurers, scoped to the questions in play.

How does the ontology handle SAR confidentiality and information barriers?

Policies in the ontology mark SAR-related information and private-side data as restricted classes. Only named roles can reach them, the restriction applies to tables, graph queries and document search alike, and refusal tests prove it before go-live. Agents working on payments or disputes never learn that a SAR exists.

Does this replace our transaction monitoring system?

No. Your monitoring platform, including any AI transaction monitoring models, keeps scoring transactions against its scenarios. The ontology adds what those scenarios lack, such as who controls an account, which merchants are related and which product rules apply, and gives triage agents and investigators the context to decide faster. Many banks later feed ontology links back into their scenarios.

How long until agents answer from the first release?

Plan on 8 to 12 weeks when the release covers 10 to 20 questions and a few systems in one business line. More legal entities, several core systems or a wide entitlement scope add time. Phase one ends by writing the production date into the SOW, and each later release gets its own date by the same route.

If we part ways with Mactores, who owns what was built?

You do. Ontology files, source mappings, rules, test sets and runbooks are kept in your AWS account and repositories in open formats, and the SOW defines IP, knowledge transfer and exit terms at signing. Stewards on your team are trained to maintain it. If the engagement ends, the system keeps running without us.

Which Transaction Would You Want Your AI to Explain First?

Bring it to us. We'll trace what your agents miss and give you a date for closing the gap.

01
Go through the transaction, its source systems and the agent's current answer in one session with an FDE.
02
Within a week, receive our findings, a proposed first-release scope and the date we would commit to.
03
Sign the fixed-fee SOW; phase one starts that week.

Every engagement includes a 30-day satisfaction guarantee. Production defects that surface in the 90 days after acceptance are repaired without charge.

Fix my transaction answers →lets-talk@mactores.com