An old-fashioned bank is building its first money transfer app. The process waits for external events — a confirmation, a timeout, a cancellation. Which one arrives first determines what happens next.
Bankoviais the kind of bank where the loudest sound is a rubber stamp hitting paper. Old-fashioned, reliable, and deeply allergic to change. But even their most loyal customers have started demanding digital services. So Bankovia's management makes a bold decision: build an app that lets customers transfer money.
Simple, right? Except that a money transfer touches multiple systems, waits for external confirmations, and needs to handle fraud, timeouts, and cancellations - all gracefully. The process behind that "Send Money" button will teach us the remaining BPMN events: event-based gateways, compensation events, and cancel events.
You already know the exclusive gateway - a diamond with an X that makes a decision based on data. "Is the shoe in stock? Yes or No." The answer is known at the moment the token arrives.
The event-based gatewayis different. It doesn't evaluate data - it waits. The token arrives at the gateway and pauses. Multiple events are defined as possible next steps - a message, a timer, a signal - and whichever event occursfirst wins. The other paths are discarded.
Think of it as a race. The gateway fires a starting pistol, and three runners take off: "confirmation received," "24 hours elapsed," "user cancelled." The first one across the finish line determines what happens. The other two stop running.
In Bankovia's transfer process, after the money is sent to the recipient bank, the event-based gateway waits. Will the other bank confirm the transfer? Will 24 hours pass without a response? The outcome determines whether the transfer succeeds or gets rolled back.
Event-based gateway: The token waits. Multiple events race. Whichever happens first wins - the other paths are discarded. It evaluates events, not data.
Sometimes work gets completed - fully, successfully completed - and then something happens that means it needs to be undone. The money was deducted from the sender's account. The transfer failed. Now you need to put that money back.
The compensation eventhandles this. Its symbol is a rewind icon - two triangles pointing backward - because that's exactly what it does: reverses completed work.
The notation has a specific pattern:
The key rule: the original task must already be completedbefore it can be compensated. You can't undo work that hasn't been done. The boundary event doesn't interrupt the task - it waits until after completion, then activates if triggered.
Compensation undoes completed work. Three parts: a boundary event on the original task, a compensation task describing the undo, and a throwing event that triggers it. You can only compensate work that's already done.
The cancel event has one purpose: cancelling a transaction sub-process. Remember that a transaction represents a logical unit of work that either succeeds, gets cancelled, or ends in a hazard (critical failure).
Cancel events come in two forms:
You can only use cancel events with transaction sub-processes - never with regular sub-processes or tasks. They exist solely for this purpose.
The transfer process starts when a customer opens the app and provides the transaction details: recipient name, IBAN, amount. The app validates that all mandatory fields are filled, then the Transaction Management System takes over.
First, it verifies the IBAN. Then two things happen in parallel (a parallel gateway):
If the fraud check passes, both tokens meet at the closing parallel gateway, and the process moves on to the actual transfer. If it doesn't - things get serious.
The fraud check fails. One or more of the three tests flags the transaction. The sub-process ends with an escalation end event, which triggers an attached escalation event on the sub-process boundary.
The alternative path kicks in: the compliance and IT security team is notified, the customer's account is temporarily blocked, and the customer is informed.
But there's a problem. The SMS TAN path already completed - that token is sitting at the parallel gateway, waiting for the fraud check token that will never arrive through the normal path. If we end with a regular end event, that waiting token stays forever. The process never finishes.
This is exactly where the terminate event earns its keep. At the end of the fraud-handling path, a terminate end event kills every remaining token in the process instance - including the one stranded at the parallel gateway. Clean shutdown.
The fraud check passes. Both tokens synchronize. The transaction sub-process begins.
First, the transfer amount is deducted from the sender's account (a script task - purely internal). Then the money is sent to the recipient bank (a service task - external API calls to the other bank's systems).
Now the process reaches the event-based gateway. It waits for one of two events:
In this scenario, the timer wins the race. No confirmation after 24 hours. The transfer failed.
The token moves through the timer event to a throwing compensation event. This triggers the compensation boundary eventattached to the "deduct amount" task. The compensation task executes: the deducted amount is refunded to the sender's account.
Simultaneously, the token reaches a cancel end event inside the transaction. This triggers the cancel boundary event on the transaction sub-process, routing to the cancellation path: an email is sent to the customer asking them to retry the transfer later.
Two mechanisms working together: compensation undoes the completed work (the deduction), and the cancel event handles the transaction-level outcome (the cancellation flow).
The transaction starts normally. The amount is deducted, the money is sent. But during the transfer, the entire Transaction Management System crashes. This triggers an attached error event on the transaction sub-process.
The error event is always interrupting - the transaction stops immediately. The alternative path investigates the error and performs mitigation actions. This is thehazard state of the transaction: neither a clean success nor a controlled cancellation, but an unexpected failure.
Remember the three outcomes of a transaction sub-process: success, cancellation, or hazard. The error event handles the hazard case.
Finally, the scenario Bankovia hopes for. The amount is deducted, the money is sent, and the event-based gateway waits. This time, the confirmation messagearrives before the 24-hour timer fires.
The token follows the confirmation path, the transaction completes successfully, and the parent process ends. The customer sees a green checkmark in the app. Done.
This is the success state of the transaction - the logical unit of work completed without cancellation or failure.
Bankovia's process is a masterclass in combining BPMN events:
Each event has a specific job. Compensation rewinds. Cancel ends transactions. Error handles crashes. Escalation bumps up. Terminate wipes the board. Knowing which one to reach for - that's what separates someone who knows BPMN notation from someone who can actually model a real process.
Interactive diagram coming soon
This will be a live Crismo canvas you can explore and edit
Model this process yourself
Open a free diagram in Crismo and build what you just learned. No signup needed.
Open in Crismo →← Nilla Care