Schematex
bpmn·OMG BPMN 2.0.2 / ISO/IEC 19510:2013·finance, banking, compliance·complexity 2/3

Loan application approval (BPMN)

Single-pool, two-lane BPMN of a bank loan approval workflow. Clerk completeness check feeds underwriter risk-scoring + review with two end states (approved / rejected). Canonical BPMN test case 7.2.

For the business analyst

Open in Playground →
bpmn·§
↘ preview
100%
Loan Application Approval BPMN LR — 1 pool(s), 8 flow object(s). Bank Clerk Underwriter yes no approve reject Application received Check completeness Complete? Risk score Underwriter review Decision Approved Rejected
UTF-8 · LF · 28 lines · 493 chars✓ parsed·3.0 ms·8.2 KB SVG

A real loan approval has more steps — KYC, fraud screening, document collection, escalation tiers — but every variant collapses onto this skeleton. The reason a flowchart doesn't suffice is the swim-lane semantics: Clerk and Underwriter are different roles with different SLAs, often different software, sometimes different legal liability. BPMN encodes that division as first-class lanes; a generic flowchart can only hint at it with shape colours.

The two XOR gateways (G1, G2) each have one conditional flow (--?) and one default flow (--*). The default flow is rendered with a slash mark at the source — it's the branch taken when no condition matches, and Schematex enforces exactly one default per gateway. Both conditional and default flows share the same gateway label ("Complete?" / "Decision"); the branch labels live on the connectors themselves.

The two end events (Approved / Rejected) sit in the underwriter lane because that's who owns the outcome. F is referenced from both gateways — the rejection path joins from either "incomplete" or "rejected" decisions, which is exactly how a human auditor would expect to read the process.

BPMN syntax