Managing Complexity in Banking Processes
Banking processes are inherently complex. A payment processing flow might have a straightforward happy path that takes five steps, but the exception handling — sanctions holds, format errors, insufficient funds, duplicate detection, nostro breaks, manual repairs — can easily involve fifty or more steps. If you try to model every detail in a single flat diagram, the result is an unreadable wall of shapes and arrows that nobody will use.
BPMN 2.0 provides three powerful mechanisms for managing this complexity: subprocesses for organising and layering detail, boundary events for handling exceptions, and compensation for undoing completed work. Together, these constructs allow you to model even the most exception-heavy banking processes in a way that is both complete and readable.
Subprocesses: Layering Detail
A subprocess is an activity that contains its own internal process — a process within a process. It is drawn as a rounded rectangle, just like a regular task, but with additional detail inside or behind it. BPMN 2.0 supports two forms:
Embedded (Expanded) Subprocess. The internal activities are shown directly within the parent diagram, enclosed in a larger rounded rectangle with its own start and end events. This is useful when the subprocess detail is relatively small (three to five steps) and the reader needs to see it in context. For example, within a payment processing diagram, you might expand a "Validate payment instruction" subprocess to show the three validation checks performed (format validation, field completeness, duplicate check) without navigating to a separate diagram.
Collapsed Subprocess. The internal activities are hidden behind a "+" marker at the bottom centre of the rounded rectangle. The detail is documented in a separate linked diagram that can be opened when needed. This is the more common approach for complex banking processes, because it keeps the top-level diagram clean and navigable. A senior manager reviewing the process can see that "KYC Due Diligence" is a step in the onboarding flow without being overwhelmed by the fifteen substeps involved. An analyst who needs the detail can drill down into the collapsed subprocess to see the full internal process.
When to use which approach? Use embedded subprocesses for small, closely related groups of steps that the reader needs to see inline. Use collapsed subprocesses for complex sections that would clutter the parent diagram — and in banking, this is the majority of cases. A well-structured BPMN model for a bank typically has a top-level process map with five to ten collapsed subprocesses, each of which expands into its own detailed diagram.
Reusable subprocesses are a related concept. A reusable (or call) subprocess can be referenced from multiple parent processes. For example, a "Sanctions Screening" subprocess might be called from the KYC onboarding process, the payment processing process, and the correspondent banking due diligence process. Instead of duplicating the same screening logic in three diagrams, you define it once and call it from each parent. This is particularly valuable in banking where common procedures — screening, four-eye verification, regulatory checks — appear across many processes.
Boundary Events: Handling Exceptions at the Source
Boundary events are intermediate events attached to the border of a task or subprocess. They represent things that can happen while the activity is being performed, and they provide an alternative path when those things occur. Visually, a boundary event is a double-bordered circle placed on the edge of a rounded rectangle, with an icon indicating the event type.
The three most important boundary event types for banking are:
Error Boundary Event (lightning bolt icon). This fires when an error occurs during the execution of a task or subprocess. The flow is immediately redirected along the exception path attached to the boundary event. In banking, this handles scenarios like a system failure during payment posting, a validation error in a regulatory report, or a failed API call to an external service.
When an error boundary event fires, the task it is attached to is interrupted — it stops executing and the process follows the exception path. This is called an interrupting boundary event (shown with a solid double border). BPMN also supports non-interrupting boundary events (shown with a dashed double border), where the original task continues while the exception path runs in parallel. Non-interrupting events are less common in banking but can be useful for scenarios like sending a notification to a supervisor when a task is taking longer than expected, without actually stopping the task.
Timer Boundary Event (clock icon). This fires when a specified duration elapses or a specific deadline is reached while the activity is still in progress. In banking, timer boundary events model SLA deadlines and timeout handling:
- A compliance review task has a 48-hour SLA. If the timer fires, the flow redirects to an escalation path where the case is reassigned to a senior analyst.
- A customer has been asked to provide additional documents. If no response is received within 10 business days, the timer fires and the application is suspended.
- A SWIFT payment has been sent and the bank is awaiting confirmation. If confirmation is not received within the settlement window, the timer fires and the operations team is alerted for manual investigation.
Message Boundary Event (envelope icon). This fires when a specific message is received while the activity is in progress. For example, while a payment is being processed through the normal validation pipeline, a cancellation request might arrive from the sending bank. The message boundary event catches this and redirects the flow to a cancellation handling path.
Error Handling Patterns in BPMN
Banking processes require robust error handling, and BPMN provides several patterns:
Catch and handle locally. An error boundary event on a task catches the error and routes it to a local handling sequence — perhaps a manual repair task followed by a retry. This is the simplest pattern and is suitable for recoverable errors. Example: a payment format error is caught, an analyst manually corrects the format, and the payment is resubmitted.
Catch and escalate. The error boundary event catches the error and routes it to an escalation subprocess, which might involve notifying management, logging the incident in the operational risk system, and assigning the issue to a specialist team. This is appropriate for errors that cannot be resolved at the operational level. Example: a sanctions screening match on a payment triggers an escalation to the financial crime compliance team.
Catch and terminate. In some cases, an error means the process cannot continue. The boundary event catches the error and routes directly to an end event. Example: a critical system outage during settlement processing triggers an immediate halt, with the process terminated and a separate incident management process initiated.
Error propagation. When an error occurs inside a subprocess and there is no boundary event to catch it, the error propagates up to the parent process. This is analogous to exception handling in programming — if the subprocess does not handle the error, the parent process must. In banking, this pattern is used for critical errors that require higher-level decision making.
Compensation: Undoing Completed Work
Compensation is one of BPMN's most powerful features for banking, where the need to reverse or undo previously completed work is a daily reality. The concept is straightforward: if a later step in a process fails, you may need to go back and undo work that was already successfully completed.
Consider a funds transfer process. Step 1 debits the sender's account. Step 2 credits the receiver's account via the clearing system. Step 3 updates the general ledger. If Step 3 fails, you cannot simply ignore the debit and credit that already occurred — you need to compensate by reversing them.
In BPMN 2.0, compensation is modelled using:
- Compensation boundary events (a double-bordered circle with a "rewind" icon, attached to the task that may need to be undone)
- Compensation activities (tasks marked with the compensation marker, connected to the boundary event via an association, defining what "undo" means for that specific step)
- Compensation throw events (triggered when the process determines that compensation is required)
For the funds transfer example, the "Debit sender account" task would have a compensation boundary event linked to a compensation activity "Reverse debit on sender account." Similarly, the "Credit receiver account" task would have a compensation boundary event linked to "Reverse credit on receiver account." If the general ledger update fails and throws a compensation event, BPMN ensures that both the debit reversal and credit reversal are executed in the correct order.
Transaction Boundaries
A transaction subprocess is a special type of subprocess drawn with a double-bordered rectangle. It groups a set of activities that must all complete successfully or all be undone — similar to a database transaction. If any activity within the transaction fails and cannot be recovered, the transaction is cancelled and all previously completed activities within it are compensated.
In banking, transaction subprocesses map naturally to settlement processes, where a series of postings must either all succeed or all be rolled back to maintain the integrity of the bank's books.
Banking Example: SWIFT Payment Exception Handling
Let us model the exception handling for a SWIFT MT103 payment to bring all these concepts together:
Top-level process (simplified to key steps):
- Start Event: "Payment instruction received"
- Collapsed Subprocess: "Validate payment instruction" (+)
- Collapsed Subprocess: "Sanctions and compliance screening" (+)
- Collapsed Subprocess: "Execute payment via SWIFT network" (+)
- Service Task: "Update general ledger and nostro accounts"
- End Event: "Payment completed"
Boundary events on the subprocesses:
"Validate payment instruction" has an error boundary event: if validation fails (malformed SWIFT message, missing mandatory fields), the flow diverts to User Task: "Repair payment instruction" followed by a loop back to retry, or after three failed attempts, End Event: "Payment rejected — return to sender."
"Sanctions and compliance screening" has a timer boundary event (2-hour SLA): if screening does not complete within 2 hours, the flow diverts to User Task: "Escalate to compliance manager for priority review." It also has an error boundary event: if a confirmed sanctions match is found, the flow diverts to User Task: "Freeze payment and notify MLRO" leading to End Event: "Payment blocked — SAR filed."
"Execute payment via SWIFT network" has a timer boundary event (settlement deadline): if the SWIFT acknowledgement is not received before the cutoff time, the flow diverts to User Task: "Initiate manual investigation with correspondent bank." It also has a message boundary event: if a cancellation request (MT192) is received from the originating bank while the payment is in flight, the flow diverts to User Task: "Process cancellation request."
"Update general ledger" has an error boundary event: if the posting fails, a compensation throw event triggers compensation on the SWIFT execution subprocess, reversing the payment.
This layered approach — collapsed subprocesses for the happy path, boundary events for exceptions, compensation for rollback — produces a process map that is both comprehensive and readable. A new team member can understand the main flow in thirty seconds. An auditor can drill into any subprocess to verify control points. An operations manager can see exactly where SLA breaches and escalations are handled.
In the next module, we will explore advanced BPMN patterns including event-based gateways, signal events, and multi-instance activities — building your ability to model even the most sophisticated banking processes.