The Problem with Unmaintained Process Maps
Creating a BPMN process map is only half the challenge. The other half — and arguably the more important half — is ensuring that map remains accurate, accessible, and useful over time. In banking, process documentation that is outdated, inconsistent, or disconnected from actual operations is worse than having no documentation at all. It creates a false sense of control, misleads auditors, and leads to decisions based on fiction rather than reality.
This module covers the governance structures, standards, and practices that transform individual process maps into a living, audit-ready process repository — a single source of truth that regulators, internal audit, risk management, and operations teams can all rely on.
Building a Process Repository
A process repository (or process library) is the centralised store where all process documentation lives. It is not a shared drive full of Visio files — it is an organised, searchable, version-controlled library with clear structure and ownership.
An effective process repository in banking should provide three things. First, a single source of truth — one place where anyone in the organisation can find the current, approved version of any process map. Second, structured navigation — the ability to browse processes by function, product, or entity, or to search for a specific process by name or keyword. Third, governance metadata — every map should carry information about its owner, version, last review date, approval status, and linked risks and controls.
The repository can be implemented in dedicated process management software (such as ARIS, Signavio, or iGrafx), in a SharePoint-based library with enforced metadata, or in a lightweight wiki structure for smaller organisations. The technology matters less than the discipline of maintaining it.
Process Hierarchy: L0 Through L3
One of the most important design decisions for a process repository is the process hierarchy — how processes are organised from the highest level of abstraction down to the most granular detail. The standard four-level hierarchy used across banking is:
Level 0 (L0) — Enterprise Value Chain. This is the highest level, showing the major end-to-end value streams of the organisation. For a bank, L0 might include: Client Onboarding, Lending, Payments, Securities Processing, Risk Management, Regulatory Reporting. Each L0 item is a broad capability area, not a detailed process. The L0 map fits on a single page and gives senior leadership and regulators a view of the entire operational landscape.
Level 1 (L1) — Process Groups. Each L0 value stream decomposes into L1 process groups. Under "Payments," for example, the L1 processes might include: Domestic Payments, International Payments (SWIFT), Direct Debits, Standing Orders, Payment Investigations. L1 maps show the major subprocesses and their relationships within the value stream. This is typically the level at which process owners are assigned.
Level 2 (L2) — Detailed Processes. Each L1 process group breaks down further into L2 processes — the individual workflows that teams execute. Under "International Payments (SWIFT)," the L2 processes might be: MT103 Single Credit Transfer Processing, MT202 Bank-to-Bank Transfer Processing, Payment Screening, Payment Repair, and Nostro Reconciliation. L2 is where your full BPMN process maps live — complete with pools, lanes, gateways, events, and exception handling. This is the level most commonly requested during audits and regulatory examinations.
Level 3 (L3) — Desktop Procedures. L3 provides step-by-step instructions for performing individual tasks within an L2 process. These are the SOPs that operators follow: "How to process an MT103 payment in the payments platform," "How to investigate a sanctions screening hit," "How to release a held payment after compliance approval." L3 documents include system screenshots, field-by-field instructions, and exception handling guidance. They are essential for training new joiners and for ensuring consistency when multiple operators perform the same task.
This hierarchy ensures that every process in the organisation has a home, and that navigation from enterprise overview to desktop procedure is logical and consistent.
Naming Conventions and Standards
Without consistent naming, a process repository quickly becomes a disorganised collection of files that no one can find. Establish and enforce naming conventions from the outset.
A practical naming standard for banking processes follows this pattern: [Entity/Division] - [L1 Group] - [Process Name] - [Version]. For example: "UK Operations - International Payments - MT103 Processing - v3.2." This convention ensures that the function, the process group, the specific process, and the version are all immediately visible.
For BPMN elements within maps, standardise how you name tasks, events, and gateways. Tasks should use verb-noun format: "Validate Payment Details," "Screen Against Sanctions List," "Release Payment to SWIFT." Gateways should state the question being asked: "Sanctions Hit?" or "Amount > Threshold?" Events should describe what triggers or terminates the flow: "Payment Received from Customer," "Settlement Confirmation Received."
Consistency in naming is not aesthetic — it is functional. When an auditor searches the repository for "sanctions screening," consistent naming ensures they find every process that includes that step, regardless of which department owns it.
Version Control
Process maps change. Systems are upgraded, regulations evolve, teams are restructured, and new products are launched. Without version control, it is impossible to know whether you are looking at the current process or a version from two years ago.
Effective version control for process documentation includes several elements. Version numbering — use a major.minor convention (e.g., v2.1). Major versions (v1.0 to v2.0) reflect significant process changes such as system migrations or regulatory redesigns. Minor versions (v2.0 to v2.1) reflect incremental updates such as a role name change or a clarification. Change log — every version should carry a brief log entry describing what changed and why. "v2.1 — Updated approval threshold from 50,000 to 100,000 per FCA guidance dated 15 Jan 2026." Approval record — each version should record who reviewed it, who approved it, and when. In banking, this approval chain is frequently examined during audits.
Never allow process maps to exist in "draft" state indefinitely. Establish a maximum time from draft to approval — 30 days is a reasonable standard — and escalate overdue approvals to the process owner's line manager.
Process Ownership and RACI
Clear process ownership is the single most critical success factor for process documentation governance. Without an owner, maps become orphaned — no one updates them, no one reviews them, and they decay into irrelevance.
The process owner is the senior manager accountable for the end-to-end outcome of the process. For an international payments process, this is typically the Head of Payments Operations. The process owner does not necessarily draw the maps themselves, but they are responsible for ensuring the documentation is current, accurate, and reviewed on schedule.
A RACI matrix clarifies roles across the documentation lifecycle. The process owner is Accountable. Business analysts or process analysts are Responsible for creating and updating the maps. Risk and compliance teams are Consulted to ensure risk and control linkages are accurate. Technology teams are Informed of process changes that may affect system requirements. Operations staff who perform the process are Consulted to validate that maps reflect reality.
Linking Processes to Risk Registers and Controls
In banking, process maps do not exist in isolation. They are a critical component of the operational risk and control framework. Regulators expect banks to demonstrate a clear linkage between the processes they operate, the risks those processes carry, and the controls that mitigate those risks.
In practice, this means each process step that carries an operational risk should reference the corresponding risk ID from the risk register and the control ID from the control framework. For example, a "Screen Payment Against Sanctions List" task in a payments process should reference the associated risk ("Failure to detect sanctioned party — Risk ID OR-PAY-012") and the control ("Automated sanctions screening with 100% coverage — Control ID CTL-PAY-045").
This traceability serves multiple purposes. Internal audit can verify that all identified risks have associated controls by following the chain from process to risk to control. Risk managers can assess the impact of a process change on the control environment. Compliance can demonstrate to regulators that the bank's processes are designed with adequate safeguards.
Audit Trail and Regulatory Expectations
Banking regulators — including the ECB Single Supervisory Mechanism (SSM), the PRA, and the FCA — have increasingly explicit expectations for process documentation. The ECB's SSM Guide to Internal Models, for example, requires institutions to document their processes for model development, validation, and governance. The PRA's Operational Resilience framework requires firms to map their important business services and the processes that support them.
What regulators look for in process documentation is straightforward: evidence that the bank understands its own operations. This means maps that are current (not years out of date), maps that reflect actual practice (not an idealised version), maps that are version-controlled with approval history, and maps that link to the risk and control framework.
An audit trail for process documentation should capture who created the map, who reviewed it, who approved it, when each action occurred, and what changed between versions. This trail should be immutable — once a version is approved, it cannot be silently edited. Any changes create a new version with a new approval cycle.
Banking Example: Building a Process Repository for Payment Processing
Consider a bank building a process repository for its payment processing operations in preparation for a PRA supervisory review.
At L0, the enterprise value chain includes "Payments" as one of eight major value streams. At L1, Payments decomposes into five process groups: Domestic Payments, International Payments, Direct Debits, Standing Orders, and Payment Investigations. The process owner for International Payments is the Head of Payment Operations.
At L2, International Payments contains six detailed BPMN process maps: MT103 Single Credit Transfer, MT202 Bank-to-Bank Transfer, MT910 Confirmation of Credit, Payment Screening, Payment Repair, and Nostro Reconciliation. Each L2 map is a full BPMN 2.0 diagram with pools, lanes, gateways, error events, and compensation flows. Each task that carries an operational risk is annotated with the risk ID and control ID from the bank's operational risk framework.
At L3, each L2 process has supporting desktop procedures. The MT103 processing map links to four L3 documents: "How to Process an MT103 in the Payments Platform," "How to Investigate an MT103 Screening Hit," "How to Repair a Rejected MT103," and "How to Reconcile MT103 Entries on the Nostro Account."
Every map carries metadata: owner, version number, last review date, approval status, and change log. The repository is searchable by process name, owner, risk ID, or control ID. The bank reviews all L2 maps annually at minimum, with event-driven reviews triggered by system changes, regulatory updates, or audit findings. When the PRA examiners arrive, the bank can demonstrate — in minutes, not days — that its payment processes are documented, current, controlled, and linked to the risk framework.
In the next module, you will learn how to connect your BPMN process maps to improvement methodologies — Six Sigma, Lean, RPA, and process mining — to drive measurable operational results.