Change policy in an afternoon
Edit the table, test the new version against recorded applications, publish. The endpoint your origination system calls does not change.
Credit decisioning
Bureau pull, affordability, scorecard, limit assignment — drawn as one flow, tested against real applications, and published the day the policy changes.
The problem
A credit policy is never finished. Cut-offs move with loss performance, a new bureau attribute arrives, a segment underperforms and needs its own tier. Each of those is a small change to the logic and a large change to the calendar when the logic lives in a service only two engineers understand.
The cost is not only speed. When the rule is buried in code, the person accountable for the loss rate cannot read it, the person who can read it is not accountable for the loss rate, and the answer to "why was this declined" is reconstructed after the fact from logs.
What the flow looks like
The applicant's data arrives against a schema you define, so a missing field is a clear error rather than a silent null halfway down the policy.
Call the credit bureau and open-banking providers you already have contracts with. The response lands in the flow as data any downstream node can read.
Turn raw bureau and transaction data into the ratios your policy actually uses — utilisation, affordability, months since delinquency — in sandboxed Python.
Points per characteristic, laid out as a table a credit analyst can read and change, not a matrix multiplication in a file.
Score bands, segment, product and channel meet in one table, with an explicit row for every combination instead of nested conditionals.
Limit and price from the score and income grid your committee signed off, kept as a grid rather than translated into code.
Applications near the line stop and wait for an underwriter instead of being forced into an automatic answer.
Approve, refer or decline, with the reasons and the version that produced them, ready for an adverse-action notice.
Data you can pull in
A Connection node calls the providers you already pay for, with your credentials. ArboRule decides which calls to make and what the answers mean together — it does not resell the data or sit between you and your vendor.
What changes
Edit the table, test the new version against recorded applications, publish. The endpoint your origination system calls does not change.
The version, the inputs, the path through the flow and the reasons are recorded with the decision — available when a customer, an auditor or a regulator asks.
Route a share of live traffic to the new version, keep it sticky per applicant, and compare outcomes before it carries everything.
Questions
Yes. ArboRule calls the providers you already have contracts with — Experian, Creditsafe, Plaid, Truv and others — using your credentials. The flow orchestrates the calls; it does not resell the data.
Whoever your workspace permissions say can. The flow is a visual graph, so a credit analyst or policy owner can edit a cut-off table directly, test it in Sandbox, and publish a version without an engineering ticket or a deploy.
Every decision records the flow version, the input, the output and the node-by-node trace of the path taken. That is the evidence behind an adverse-action notice or a regulator's file review, reproduced from the run itself rather than reconstructed from logs.
Ready when you are
Build the flow in Sandbox, run your own cases through it, and see the trace before anything reaches a customer.