Loan Origination: Correcting a BPMN Model Before Approval

First, a single pool mixes the bank and the customer, who are separate participants. The customer should be a separate pool or at least an external participant, with message flows for application submission and notification. Mixing them obscures responsibility and makes the model non-executable across organizational boundaries. Second, putting all tasks in one lane defeats the purpose of lanes. The model should use lanes for intake, credit scoring, credit review, fraud, compliance, contract generation and customer communication, so handoffs and accountability are visible. Third, exclusive gateways after a parallel split are wrong if both fraud and compliance checks must complete before contract generation. The split should be a parallel gateway, and the clearing branches should converge at a parallel join. Exclusive gateways may still be used inside each branch to test stop versus clear. Fourth, the timer boundary event is attached to the wrong activity. A 48-hour reminder while credit review remains open belongs on the credit review task or a surrounding subprocess, and it should normally be non-interrupting so the review continues. Attaching it to send-decline would notify the team leader only after a decline, which is not the stated rule. Fifth, the rule that either check can stop the application while the other continues needs explicit cancellation semantics. A plain parallel join waits for both branches; if one stops, the other may leave a dangling token. The model needs an interrupting event subprocess or a terminate end event, or a redesign using an event-based gateway, to show that a stop flag cancels the remaining check.

A workable pattern is a parallel split into fraud screening and compliance checking. Each branch contains an exclusive data-based gateway that routes to either a clear path or a stop path. The clear paths converge at a parallel join, after which contract generation can start. The stop paths lead to a shared decline path, but that path must cancel the other branch. Standard BPMN parallel joins wait for all incoming tokens, so a simple merge will not express 'either stop cancels the other check'. One option is to wrap the two checks in a subprocess and use an interrupting error event or terminate end event when a stop flag occurs. An event subprocess with an interrupting error start event can catch the stop and route to decline. Another option is to model the two checks with an event-based gateway followed by a subprocess, though that changes the semantics. The modeller should state the chosen convention in an annotation, because BPMN does not have a native 'cancel sibling branch' construct that all tools interpret identically. The model must also show who performs each check, what data is exchanged, and how the customer is notified. For audit purposes, the model should not hide the stop decision inside a task name; the gateway condition and the event must be explicit.

Use two pools: customer and bank. Inside the bank pool, use lanes for application intake, credit scoring, credit review, fraud screening, compliance checking, contract generation and customer communication. Put the fraud and compliance work inside a subprocess called Perform risk checks, with a parallel split and join and an interrupting stop event. Keep the credit review as a separate subprocess or task with a non-interrupting boundary timer at 48 hours that notifies the team leader. Use message flows for the customer's application and the bank's decision notification. Name tasks as verb plus object, for example Calculate credit score, Review credit application, Screen for fraud, and Generate loan contract. For governance, first require a structured review against the process owner's rules: every gateway has a labelled condition, every event has a trigger and outcome, every lane has an owner, and every message flow crosses a pool boundary. Second, require traceability: link each model element to the policy or requirement it implements, version the model, and record who approved changes. A simulation or token walkthrough should test the 700 score threshold, the 48-hour path, the stop path and the both-clear path. Readability and auditability are not cosmetic; they determine whether the model can be used for training, automation and control evidence.