The customer#
BFI Finance is an Indonesian multifinance company that finances over 9,000 loans per day across two-wheel and four-wheel vehicles, and other consumer and commercial assets. For years, loan origination ran through a single system built for a mature, human-centric process: applications moved step by step through onboarding, survey, underwriting, and approval, with BFI personnel, agents, surveyors, and credit analysts central to every step.
That model served BFI well for its agency and dealer financing channels. But a new wave of growth, driven by Digital Partnership integrations with ride-hailing, e-commerce, digital bank partners, and EV2W platforms, needed a fundamentally different process: high automation, minimal human touch, fast experimentation, and the ability for business teams to evolve products independently.
"None of that was something the original architecture was built for," said Justinus Okky Munindra Permana (Okky), Technology Head at BFI Finance.
The challenge#
BFI's original loan origination system, orchestrated with BPMN and Camunda, had real strengths for its original purpose, but its architecture came with tradeoffs that grew painful as digital channel volume increased:
- A control structure originally designed around established organizational roles that became less flexible as digital business processes evolved
- An effectively one-way pipeline, with no clean mechanism to step back for a data correction or additional input
- Only local visibility into where any given application actually stood in the process
- Tight coupling between flow, code, and data, making it complex to introduce rapid process changes safely without expanding edge cases
BFI wanted to move away from a fixed pipeline model toward a data-centric approach organized around the application document itself. In this model, each process step declares the data it needs and the data it produces, and execution order is derived dynamically from that, an approach the team grounded in the academic Guard-Stage-Milestone (GSM) model for business entity lifecycles and then extended for its own use.
Making that model work in production required something durable underneath it: infrastructure that could survive Worker crashes and multi-day pauses for human review (a survey step, for example, can sit "alive" for days waiting on a customer) without BFI having to hand-roll its own recovery logic. That requirement led the team to Temporal.
As Okky put it, adopting a Durable Execution engine let BFI "decouple orchestration reliability, which is Temporal's job, from business process design, which is our job," rather than continuing to build both from scratch inside Camunda.
The solution#
BFI developed its own Loan Origination framework on top of Temporal and called LORA (Loan Origination ReArchitecture). Temporal now orchestrates the full loan origination lifecycle for BFI's partnership and digital channels, branded internally as NDF (Non Dealer Finance), spanning both two-wheel and four-wheel products. That includes:
- Automated credit scoring and risk decisioning: customer checks, anti fraud checks, and collateral checks
- Human-in-the-loop review: surveys, credit analyst review, asset document review
- Go-live operations: CIF creation, agreement issuance, and asset document tracking
- Revolving loan processing for eligible returning customers
Architecturally, two purpose-built Go Workers sit behind BFI's Gateway, Schema, and Task services, each on its own Temporal Task Queue:
- Lora Process Worker (LPW), which handles automated processing and decisioning, including scoring and automated data gathering from third-party services
- Lora Task Worker (LTW), which handles human-in-the-loop work such as surveys, credit analyst review, and asset document review
LPW and LTW coordinate through Temporal Signals: LPW pauses and signals LTW to start a Task Workflow whenever a human step is required, and LTW signals back on completion so LPW can resume. Sub-processes such as e-signing, appointment scheduling, and cancellation run as Child Workflows.
On top of the core Temporal SDK, BFI built an internal Process SDK that auto-registers every business process step, declared through a JSON Schema readset (the input data a process read) and writeset (the output data a process writes), as a Temporal Activity. A custom planner determines execution order dynamically from that schema, so BFI's core scoring Workflow runs with effectively no hand written Activity sequencing: the shape of the data drives the shape of the execution.
LORA Architecture Diagram
Orchestration in LORA
Getting there required a real mindset shift. According to Okky, the move from an explicit flow, BPMN-style mental model to a data-driven, declarative one was the biggest conceptual change for the engineering team. It also demanded new discipline around schema definitions, guarding against "field rot" and "field creep," which the team supported with investment in code generation.
Temporal capabilities BFI relies on most#
- Durable execution and automatic Replay: a Worker crash mid Workflow requires no special handling. Temporal uses the Workflow’s Event History to reconstruct its state through Replay and continue execution.
- Signals: used to cleanly separate automated and human-driven concerns into independent, independently scalable Workers while keeping them coordinated.
- Built-in retry policies: absorb the constant churn of flaky external dependencies, including scoring providers, KYC services, and partner APIs.
- Workflow reset: used sparingly, for rare cases that require re-execution from a prior point, such as correcting bad data that already entered the process.
- Task Queue versioning: tied to BFI's document schema version, allowing old and new Worker versions to run concurrently during rollout so in-flight applications finish on the version they started on.
The results#
- 80+ scoring activities in the main scoring Workflow
- 100+ activities registered across the platform overall
- 25+ survey and task form definitions on the human-in-the-loop side
- 4,000 Digital Partnerships Loans processed per day, 24/7, representing approximately 70–80% of BFI’s current daily loan volume.
The takeaways#
BFI sees this Temporal-based orchestration foundation becoming the default approach for new loan products and channels, rather than a one-off solution for the digital partnership use case alone. That shift is already underway. Other loan products, starting with revolving loans for returning customers, are moving onto LORA, reusing the same Process SDK and schema-driven document model with no changes to the core orchestration layer. Beyond heavy business processes like loan origination, BFI has also started adopting Temporal more broadly wherever durable orchestration pays off. Examples include data pipelines migrated from Airflow, services that aggregate data from multiple downstream systems before they can act, and long-running, multi-step procedures that need to survive failures and pick up where they left off.
Advice for other financial institutions#
Asked what he'd tell other financial institutions considering a similar transformation, Okky offered three points:
- Get the data model and schema discipline right before choosing an orchestration approach. A durable execution engine amplifies whatever process model sits on top of it, so it's worth deciding up front whether a fixed, BPMN-style flow or a data-driven, declarative model fits your process maturity and rate of change.
- Separate automated and human-driven work into distinct Workers and Task Queues early. For BFI, this made independent scaling and reasoning about failure modes far simpler.
- Don't underestimate the value of a thin internal SDK layer over the raw Temporal SDK. For BFI, this provides a consistent way to enforce Workflow determinism and schema standards, embedding engineering best practices directly into the development process rather than relying on individual developers to remember and apply them.
