Bankovia: Event-Based Gateways, Compensation & Cancel Events in BPMN

A Bank Joins the 21st Century

Bankovia is 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**.

  ## The Event-Based Gateway: A Race Between 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 gateway is 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 occurs
first 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.

  ## The Compensation Event: Rewinding the Tape

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 event handles 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:

  - A **compensation boundary event** is attached to the task that might need
      undoing. It's connected by a dashed association line to a compensation
      task that describes *how* to undo the work.

• A throwing compensation event (intermediate or end) triggers the compensation. When the token reaches it, the attached compensation boundary event fires, and the compensation task executes.

The key rule: the original task must already be completed before 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: Ending a Transaction

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:

  - **Cancel end event** - placed *inside* the transaction sub-process.
      When the token reaches it, the transaction is cancelled.

• Cancel boundary event - attached to the outside of the transaction sub-process. It catches the cancellation and routes the token to an alternative path.

You can only use cancel events with transaction sub-processes - never with regular
sub-processes or tasks. They exist solely for this purpose.

  ## Bankovia's Money Transfer: The Setup

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):

  - **SMS TAN authentication** - a one-time code is sent to the customer's
      phone. They enter it, the system verifies it.

• Fraud check sub-process - three automated checks run in sequence: checking user metadata for irregularities (script task, internal data), verifying recipient account credibility (service task, external APIs), and comparing the transaction against known fraudulent patterns.

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.

  ## Scenario 1: Fraud Detected

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.

  ## Scenario 2: Bank Not Reachable

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:

  - A **confirmation message** from the recipient bank.

• A 24-hour timer - if no confirmation arrives in time.

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 event attached 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).

  ## Scenario 3: System Failure

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 the
hazard 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.

  ## Scenario 4: The Happy Path

Finally, the scenario Bankovia hopes for. The amount is deducted, the money is sent,
and the event-based gateway waits. This time, the confirmation message
arrives 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.

  ## How the Pieces Fit Together

Bankovia's process is a masterclass in combining BPMN events:

  - **Event-based gateway** - waits for whichever event arrives first
      (confirmation vs. timeout). Use when the next step depends on external events
      outside your control.

• Compensation - undoes completed work (refunds the deducted amount). Use when a later failure means earlier successful work needs to be reversed.
• Cancel event - ends a transaction sub-process and triggers a cancellation flow. Use with transaction sub-processes to handle controlled cancellations.
• Error event - handles system failures (the hazard state). Use for unrecoverable technical failures.
• Escalation event - routes fraud detection to the compliance team without crashing the process. Use when a problem needs attention but the response is a defined alternative path.
• Terminate event - kills orphaned tokens (the one stuck at the parallel gateway after fraud detection). Use when other tokens would be stranded without it.

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.

---

This is part of the Learn BPMN series on ProcessCamp - 11 real-world scenarios to master process modeling. Try modeling this yourself in Crismo - free, no signup needed.