How MUFG Bank aims to cut flowchart work by up to 90% with ontology-grounded AI on Amazon Neptune and Amazon Bedrock

MUFG Bank, Ltd. processes approximately 200,000 daily transactions across roughly 30 countries, with over 3,000 employees running deposits, remittances, loans, trade finance, and market operations. Remittances alone account for 86 percent of daily volume, making them the highest-value workload where accelerating the system-development effort behind standardization would compound the fastest. Yet after two decades of overseas growth, only about 10% of these operations had been centralized. The remaining 90 percent ran on branch-specific procedures written and maintained locally, producing significant variance in quality, cost, and delivery from one country division to the next.

Today MUFG’s Global Operations Planning Division is closing that gap with a custom-developed application called AI Flowchart, which grounds generative AI using structured domain models on top of Amazon Neptune and Amazon Bedrock. Since going live, AI Flowchart is expected to cut the system-development effort behind each branch-procedure standardization from 11 person-days to 1 person-day. That’s a reduction of up to 90 percent, with individual flowchart creation down 95 percent. That acceleration is intended to free MUFG’s operations experts to focus on the standardization decisions themselves, rather than on the flowchart authoring, comparison, and revision cycles that precede them. In this post, we walk through the problem MUFG set out to solve, why generative AI alone was not enough, and how ontology made the solution production-ready.

MUFG’s overseas operations

MUFG Bank’s overseas operations span approximately 30 countries. Its Global Operations Planning Division oversees the back-office of the bank’s global footprint. Remittances are the dominant workload (86 percent), followed by market operations (8 percent), deposits (3 percent), loans (2 percent), and import/export (1 percent). The department’s strategic vision is to deliver three-way benefits to customers in Quality, Cost, and Delivery through three pillars: standardization, automation, and centralization.

Challenge: Branch-specific procedures at scale

For over 20 years, MUFG’s overseas business grew faster than its ability to standardize the operations underneath it. Each branch developed its own variant of head-office procedures to accommodate local regulation, correspondent-bank relationships, and legacy tooling. The result was a matrix where the same MUFG product family (say, remittances) had a different procedure in mega branches in the US, UK, and Asia, even though the head-office standard was identical.

Bringing that matrix under control required expert operators to author a flowchart of each branch’s procedure, compare it against another branch or the head-office standard, coordinate revisions with stakeholders, and revise the flowchart to close gaps. Each of these steps is system-development work that precedes any actual standardization decision, and each was the bottleneck. The effort was planned as follows:

1. Flowchart creation took approximately 10 person-days per branch per procedure.
2. Flowchart comparison was pairwise and manual (1 branch compared against 1 branch), roughly 0.5 person-days per comparison.
3. Stakeholder coordination consumed 1–2 person-months per case.
4. Flowchart revision added another 0.5 person-days.

The total was about 11 person-days of expert system-development work per branch procedure, plus 1–2 person-months of stakeholder coordination before a standardization decision could even be tabled. With hundreds of branch-procedure combinations across five MUFG product families, the backlog was structurally unmanageable, and MUFG had a broader deadline behind it: Japan’s “2030 problem” of accelerating labor shortages was making manual knowledge transfer increasingly unsustainable.

A first attempt: Generative AI alone wasn’t enough

In late 2024, MUFG’s team began experimenting with generative AI to automate the flowchart authoring step. Between January 2025–May 2025, they ran a proof of concept (PoC) using foundation models (FMs) directly on branch procedure documents.

The result was disappointing. Flowchart quality was inconsistent from run to run. Comparisons between branches were unreliable because the model would silently invent steps that weren’t in the source procedure. In MUFG’s words, the flowcharts created using only large language models (LLMs) were unusable. The team needed a way to force the model to reason within the actual vocabulary and structure of MUFG’s operations, not the model’s own approximation of it.

Solution: Ontology and knowledge graph grounding layer

In January 2025, MUFG proposed adding two connected layers beneath the LLM: an ontology that defines the business concepts, relationships, and rules, and a knowledge graph that organizes MUFG’s actual process and policy information according to that model. The team represented this model using the Resource Description Framework (RDF), which expresses entities and relationships as graph data, and the Web Ontology Language (OWL), which gives those concepts and relationships machine-readable meaning. In February 2025, MUFG began a joint engagement with AWS Specialists and AWS Professional Services. The team then moved into full development of a custom ontology solution built with AWS for this pattern.

The ontology is built on one premise: an AI agent is like a highly skilled new employee with no business knowledge. Before it can be trusted to produce work that a bank operations expert would sign off on, it needs to be taught the domain, given real cases to work from, and corrected when it assumes things that are not true. The solution provides three capabilities that make that possible on AWS:

1. An ontology (the domain blueprint). MUFG’s business experts and the AWS team extracted the concepts, actions, and relationships from head-office procedures (for example, “Payment information → populate → mandatory fields”, “Officer → execute → remittance”). These triples became the ontology, a shared schema that defines what a valid remittance procedure looks like at the concept level, independent of any branch.
2. A knowledge graph (branch-level instances). Each branch’s actual procedure (mega branches in the US, UK, and Asia) was mapped against the ontology and loaded into Amazon Neptune as a populated instance graph. The ontology is the blueprint. Each branch’s knowledge graph is a building constructed from that blueprint.
3. An AI agent that queries the graph before generating. Instead of letting Amazon Bedrock generate a flowchart from raw text, the agent first retrieves the relevant subgraph from Neptune, uses it to constrain what the LLM is allowed to output, and cites the specific nodes and edges that support each step. Hallucinations drop sharply because the model is no longer free to invent structure that doesn’t exist in the ontology. For example, when asked to generate the flow for a cross-border payment, the agent retrieves the subgraph connecting Payment Request → Cross-Border Payment → Mandatory Field Validation → Sanctions Screening → Authorization. It also retrieves the threshold conditions and policy references attached to those relationships. Instead of generating a flowchart from raw text, the agent uses this subgraph to constrain the steps and branches the LLM can include, then cites the specific nodes and edges supporting each step.

An important nuance: the ontology does not standardize MUFG’s procedures. Standardization remains a business decision made by MUFG’s operations experts and regional stakeholders. What the ontology delivers is a dramatic acceleration of the system-development work that precedes each of those decisions: authoring flowcharts, comparing them at portfolio scale, and revising them once a target state is agreed. The humans stay in the loop. The tooling stops being the bottleneck.

Architecture

AI Flowchart is a serverless application on AWS. The end-to-end architecture includes:

1. Frontend: Ontology web application.
2. API and identity: Amazon API Gateway and Amazon Cognito for authenticated REST access.
3. Ingestion: A set of AWS Lambda functions for document upload, presigned Amazon Simple Storage Service (Amazon S3) URLs, metadata updates, and preprocessing. Artifacts land in dedicated S3 buckets for raw documents, preprocessed files, finalized outputs, and session history.
4. Ontology data creation: Amazon Bedrock foundation models (LLMs) and AI agents infer ontology descriptions from actual MUFG business and system documents and generate them in RDF/OWL (OWL 2 DL profile).
5. Stored ontology data: Amazon Neptune stores the ontology and per-branch knowledge graphs.
6. Ontology reasoning: HermiT runs as a reasoning component between Amazon Neptune and the AI agent. For each request, the application retrieves the relevant ontology and branch-level subgraph from Neptune and passes the RDF/OWL data to HermiT. HermiT evaluates the ontology, derives relationships implied by OWL, and returns the inferred facts to the agent.
7. AI agent inference: The Strands Agents-based agent orchestrates the two parts of the neuro-symbolic architecture. It invokes Amazon Bedrock for language-model inference and HermiT for ontology reasoning, then uses the inferred facts and supporting graph data to generate and cite its response.

Figure 1: End-to-end AI Flowchart serverless architecture on AWS

Results

Between the first PoC and the launch, MUFG measured the per-case workload of the three AI-assisted steps (create, compare, and revise) against the prior manual baseline.

Two effects go beyond the per-case number:

1. Portfolio-scale comparison. The pre-AI workflow compared one branch against one branch. AI Flowchart compares one branch against N branches simultaneously, because the ontology lets the agent normalize each branch’s procedure to a common representation before diffing. Portfolio-level analysis that was previously infeasible is now the default view.
2. Reviewer-not-author. The expert’s role is being shifted from authoring flowcharts and comparing them manually to reviewing AI-generated output. That’s what makes the 90 percent number durable rather than one-shot. The time saved compounds across every new branch and procedure family, and the expert judgment that drives standardization is now the scarce resource, not the flowchart authoring behind it.

The team has already begun applying the same ontology and knowledge graph pattern to adjacent problems: user acceptance testing (UAT) test-case creation (started March 2026), requirements-definition document generation, knowledge-transfer automation, mergers and acquisitions (M&A) operational due diligence, and new-branch openings. Going forward, UAT test-case creation will also use the Context Ontology Accelerator, an open-source ontology project from AWS that grounds generative AI in a structured domain model.

Why this pattern generalizes

MUFG’s insight isn’t specific to banking. Many regulated enterprises that have grown by acquisition or geographic expansion carry the same structural cost: head-office standards on top, branch-, subsidiary-, or region-specific procedures underneath, and no scalable way to develop the artifacts (flowcharts, comparisons, revisions) that would let their experts converge those procedures on a common standard. Generative AI alone won’t close the gap because the model has no principled way to know what a valid procedure looks like in your domain. The ontology-grounded pattern gives your experts a system-development accelerator so that the standardization work itself becomes the constraint, not the tooling around it.

“Beyond convenient usage of AI, education is essential, and that is a role uniquely suited to user departments that possess deep business expertise.”

— Naoki Mizoguchi, MUFG Bank, AWS Summit Japan 2026

Getting started

1. If you want to build an ontology for your AI solutions and projects, read the Context Ontology Accelerator project overview for an end-to-end tour of the ontology, knowledge graph, and agent components.
2. If you want AWS Specialist and AWS Professional Services support on an ontology and knowledge graph engagement of your own, reach out to your AWS account team.

About the customer

MUFG Bank is a core banking subsidiary of Mitsubishi UFJ Financial Group. Its Global Operations Planning Division is responsible for the standardization, automation, and centralization of overseas administrative operations across MUFG’s global network. Learn more at www.mufg.jp.

About the authors