Why Organisational Context Matters
In Module 2, we learned the fundamental elements of BPMN 2.0 — events, activities, gateways, and flows. But a process diagram that shows only the sequence of tasks without indicating who performs each step is incomplete. In banking operations, where every process involves handoffs between front office, middle office, back office, compliance, and often external parties, understanding organisational responsibility is critical.
Consider a KYC onboarding process. The relationship manager collects initial customer information. The compliance team performs due diligence checks. The operations team opens the account in the core banking system. An external identity verification provider confirms document authenticity. A credit bureau supplies background data. Without clearly showing these distinct participants and the handoffs between them, your process map becomes an ambiguous sequence of steps where nobody knows who does what — precisely the kind of documentation that fails an audit.
BPMN 2.0 addresses this with two powerful constructs: pools and lanes (also called swimlanes). Together with message flows, they allow you to model complex, multi-party processes with clarity and precision.
Pools: Representing Major Participants
A pool in BPMN 2.0 represents a major participant in a process — typically an organisation, a business entity, or a major system. Visually, a pool is drawn as a large horizontal (or vertical) rectangle that contains an entire process or a portion of one. The pool's label identifies the participant.
In banking process mapping, common pools include:
- The bank itself — containing all internal departments and activities
- External regulators — such as the FCA or ECB (when modelling regulatory reporting)
- Third-party providers — such as SWIFT, identity verification services, credit reference agencies, or correspondent banks
- The customer — when you need to show customer-facing interactions
A critical rule: sequence flows cannot cross pool boundaries. All connections between pools must use message flows (dashed arrows). This rule enforces the principle that you cannot dictate or control the internal process of another organisation — you can only exchange messages with them.
When you are modelling an external party whose internal process you do not know or control, you can represent them as a collapsed pool — a narrow rectangle with just a label and no internal detail. For example, a credit reference agency might appear as a collapsed pool labelled "Credit Bureau" at the top of your diagram, with message flows going to and from it, but no internal tasks visible. This is both practical and accurate — you are documenting the interaction, not the other party's internal workflow.
Lanes: Subdividing Responsibilities Within a Pool
Lanes (or swimlanes) subdivide a pool into horizontal or vertical bands, each representing a role, department, or function within the organisation. Every task, event, and gateway is placed within the lane of the responsible party.
For a bank's KYC onboarding pool, typical lanes might include:
- Relationship Manager — responsible for client interactions, document collection, and initial data capture
- KYC/Compliance Team — responsible for due diligence checks, sanctions screening, risk assessment, and approval or escalation
- Operations — responsible for account setup, system configuration, and issuance of account credentials
- Senior Management — responsible for approval of high-risk clients or exception decisions
When a task moves from one lane to another, the sequence flow arrow crosses the lane boundary. This visually highlights every handoff in the process — and handoffs are where most delays and errors occur in banking operations. By making handoffs visible, you create an immediate diagnostic tool: if your diagram shows a task bouncing between four lanes six times, you have identified a process that probably needs to be streamlined.
Best Practices for Pools and Lanes
Name lanes by role or department, not by individual. Use "Compliance Analyst" or "KYC Team" rather than "Sarah Jones." People change roles; the process documentation should outlive any individual.
Keep the number of lanes manageable. A process map with twelve lanes becomes unreadable. If you find yourself with more than five or six lanes, consider whether some roles can be consolidated or whether the process should be broken into subprocesses (covered in Module 4).
Use separate pools for external parties. A common mistake is placing an external vendor or a correspondent bank as a lane inside the bank's pool. This implies the bank controls their process, which is incorrect. External parties should always be separate pools, connected via message flows.
Align tasks horizontally to show time progression. While BPMN does not formally require a time axis, placing tasks from left to right in rough chronological order makes diagrams much easier to read. Most banking process maps follow a left-to-right flow within each lane.
Show data artefacts at handoff points. When a process moves from one lane to another, it is helpful to attach data objects showing what is being passed. For example, when the KYC team passes an approved file to operations, a data object labelled "Approved KYC file with risk rating" clarifies exactly what the receiving team gets.
Message Flows Between Pools
Message flows are dashed lines with an open circle at the source and an open arrowhead at the destination. They represent communications that cross organisational boundaries — emails, API calls, SWIFT messages, file transfers, or any form of inter-organisational exchange.
In banking, common message flows include:
- Bank to SWIFT network — sending payment instructions (MT103, MT202)
- Bank to identity verification provider — submitting identity documents for validation, receiving verification results
- Bank to regulator — submitting regulatory reports (COREP, FINREP, STRs)
- Bank to customer — sending notifications, requesting additional documents, providing account credentials
- Bank to correspondent bank — nostro/vostro confirmations, payment status queries
A message flow connects an element in one pool to an element in another pool. It can connect to a specific task (showing exactly which activity sends or receives the message) or to the pool boundary (indicating that the message enters the pool without specifying which internal task handles it).
Remember: message flows represent asynchronous communication. When the bank sends a verification request to an external provider, the bank's process may need to wait for a response. This waiting period is typically modelled with an intermediate message catch event — a double-bordered circle with an envelope icon, placed in the bank's process to show where the flow pauses until the external response arrives.
Banking Example: KYC Onboarding With Pools and Lanes
Let us model a KYC onboarding process that shows the full organisational picture. The diagram contains the following participants:
Pool 1 — The Bank (expanded, with three lanes):
- Lane: Relationship Manager
- Lane: KYC/Compliance Team
- Lane: Operations
Pool 2 — Identity Verification Provider (collapsed)
Pool 3 — Customer (collapsed)
The process flows as follows:
- Customer pool sends a message flow: "Application submitted" to the Relationship Manager lane.
- Relationship Manager lane — User Task: "Log application and capture initial data." Sequence flow to User Task: "Review document completeness."
- Exclusive Gateway: "Documents complete?"
- No path: Message flow back to Customer pool: "Request missing documents." Intermediate Message Catch Event: "Await customer response." Then loop back to document review.
- Yes path: Sequence flow crosses lane boundary into the KYC/Compliance Team lane.
- KYC/Compliance Team lane — Service Task: "Run automated sanctions and PEP screening." Simultaneously, a message flow is sent to the Identity Verification Provider pool: "Submit documents for verification." An Intermediate Message Catch Event waits for the provider's response message flow: "Verification result received."
- User Task: "Perform risk assessment and assign customer risk rating."
- Exclusive Gateway: "Risk rating within acceptance threshold?"
- No path: User Task: "Escalate to senior compliance for decision." Then Exclusive Gateway: "Approved?" — leading to either proceeding or End Event: "Application declined."
- Yes path: Sequence flow crosses lane boundary into the Operations lane.
- Operations lane — Service Task: "Create customer profile in core banking system." Service Task: "Generate account credentials."
- Message flow to Customer pool: "Account credentials and welcome pack sent."
- End Event: "Onboarding complete."
This diagram makes several things immediately visible: every handoff between departments, every external communication, where the process waits for external responses, and where decisions are made. An auditor reviewing this map can instantly identify the control points (sanctions screening, risk assessment, senior approval for high-risk clients) and verify that they are in the right places.
Common Mistakes to Avoid
Crossing pool boundaries with sequence flows. This is the single most common error. If two participants are in separate pools, the only connection between them is a message flow. Sequence flows stay within pools.
Putting external parties in lanes. A correspondent bank, a regulator, or a vendor is not an internal department. Give them their own pool.
Forgetting to model the wait. When you send a message to an external party, your process does not continue instantly. You need an intermediate catch event or a receive task to model the fact that you are waiting for a response.
Overcomplicating the diagram. Start with the main process path and the key participants. Add detail incrementally. A diagram that tries to show everything at once becomes unreadable and defeats its purpose.
In the next module, we will learn how to manage complexity by using subprocesses, error handling, and compensation — essential techniques for modelling the exception-heavy processes that define banking operations.