Configurable Underwriting Decision Workflow for US Payday Lender
Configurable by ops
Summary
We designed and specified an operational underwriting workflow system for a major US payday lender. The system gives the underwriting team a single, rule-driven interface to process leads end-to-end: from lead intake to an accept/decline decision, with business rules, credit bureau integrations, and A/B testing fully configurable by operations—no engineering required for routine changes.
Domain: Financial Services Operations · Lending · Risk & Compliance
Process type: Decision-heavy, rule-based underwriting with multi-source data and experimentation
The Client Situation
A large US payday lender needed to scale underwriting operations without turning every rule change or test into an engineering ticket. Leads flowed in from multiple channels; underwriters had to apply a growing set of business rules, pull data from several credit reporting agencies, and run controlled experiments (A/B tests) on decision logic—all while keeping decisions consistent, auditable, and configurable by the business.
The pain was twofold: throughput (underwriters bottlenecked by fragmented tools and manual checks) and agility (every rule or test change required dev involvement and release cycles).
What We Delivered
We led business process discovery and requirements definition for an underwriting workflow platform (the client or their implementation partner built from our spec). During discovery we surfaced opportunities they hadn’t fully considered—for example, A/B testing of business rules so operations could experiment with score cutoffs and approval thresholds without engineering. The delivered design included:
Single workflow interface
A GUI built around the underwriting process: one place where the team sees the lead, all relevant data, and the path to a final decision (accept/decline). The flow is defined by configurable business rules, not hard-coded logic.Rule-driven decision engine
The system applies a predefined set of business rules in the background. Rules can reference credit scores, bureau data, internal flags, and product parameters. Operations defines and maintains these rules through the same interface—no code deploys for routine policy updates.Credit bureau and data integrations
The workflow automatically pulls information from multiple credit rating agencies and other data sources. Underwriters see a unified view; the system uses this data as inputs to the rule engine.A/B testing of business rules
An A/B testing mechanism gave the operations manager the ability to test different business rules in production (e.g. alternate score cutoffs, rule sets, or approval thresholds) on a share of traffic. They could compare which variants performed better before rolling out changes—all configured and analyzed through the GUI, without engineering.Operational ownership
An operational manager can set up and adjust business rules, thresholds, and test plans through the GUI. The result is a production decision workflow that the business owns and evolves, with IT focused on platform reliability and integrations rather than every rule change.
Why a dedicated decision platform (and when n8n isn’t enough)
Tools like n8n excel at orchestrating workflows: connecting systems, moving data, and automating steps. This engagement needed something different—an intelligent decision layer that operations could configure and experiment on, not a flowchart only developers can change.
Business-defined rules, not developer-defined nodes
The client needed operational managers to create and edit business rules (e.g. “if bureau score below X and product = Y, then …”) in a dedicated interface. In n8n, logic lives in workflow nodes; changing rules means editing the workflow and deploying. Here, rules are first-class, versioned, and auditable—so the business can iterate without touching the automation backbone.First-class A/B testing of decision logic
Testing different business rules required traffic splitting, variant assignment, and outcome tracking built into the product. That’s a decision-experimentation feature, not just a branch in a workflow. A dedicated platform could support it natively; a generic workflow tool would need heavy custom logic and still be hard for ops to own.Multi-source data and compliance
Underwriting pulls in multiple credit bureaus, internal flags, and product parameters, with strict audit and lineage requirements. The solution needed a clear “decision engine” abstraction—inputs, rules, decision, audit trail—rather than a long chain of steps that’s harder to reason about and certify.Right tool for the job
We’re tool-agnostic: when the job is “connect these systems and automate steps,” we use n8n or similar. When the job is “let the business define and test decision logic at scale,” we design (or integrate with) a dedicated decision platform. This use case is the latter—and the same mindset applies when we add AI/ML into the loop: the decision layer is where models and rules live together.
Outcome
We delivered end-to-end process discovery and requirements for an intelligent underwriting decision workflow that turned lead-in/decision-out into a single, configurable process. The client gained a system where business rules, credit data, and A/B tests are managed by operations—reducing rule-change cycle time from dev-led releases to ops-led configuration—with an architecture that can later plug in AI/ML scoring or AI-assisted exceptions without rebuilding the workflow. Faster policy iteration, consistent decisions, and a clear path from rules to AI-powered decisions on the same foundation.