Credit changes tested in 1 to 2 hours, down from five working days

The team configured credit decisioning engines for banks across credit cards, auto loans, personal loans and SME lending. Each engine is built from input variables, formulas, logic tables, scorecards and decision trees. Together they decide if an applicant is approved, referred to manual underwriting, or declined.

Banks send change requests constantly: a new card product, a policy change for one segment, such as self-employed applicants, a revised cut-off. Each change lands on an engine that has grown for years. Many of the analysts who set it up have moved on. Before any change, someone has to work out what the engine does today. That step was manual, slow and error prone.

Stage	What it does	Status
1Read the setup	Parses the live configuration and maps how every rule connects	Live
2Find the gaps	Compares the requirements document with each environment	Live
3Build the tests	Generates and runs test cases against the engine	Live
4Protect the data	Removes personal and bank identifying data before any cloud model sees it	Live
5Report the results	Produces a working report for the credit team and a summary for executives	Live

Before. An analyst who gets a change request on a setup they did not build needs a few hours of focused work to understand it. In practice that work is split across other clients and deadlines. Context is lost between sessions. Analysts often needed a senior analyst to walk them through it, or contacted the person who originally configured it. The elapsed time was typically 5 or 6 working days.

Now. The agent parses the configuration directly. It maps the decision trees. It traces each rule's upstream inputs and downstream effects. So it shows which variables, scorecards and outcomes a change will touch. The analyst starts with a complete map of the setup within minutes.

Before. The business requirements document (BRD) is meant to be the single source of truth for the engine. Over years of change requests and quick fixes, the document and the live setup drifted apart. Matching them again meant a line by line review that took about three days.

Now. The agent compares the BRD with the configuration in all three environments: development, user acceptance testing (UAT, where the bank signs off a change) and production. It checks input variables, formulas, logic tables, scorecards and decision trees. For each gap it reads recent client emails and decisions. It suggests which side is correct, then drafts the fix to the document or the setup. An analyst reviews and approves every change before it is applied.

Before. Analysts built test cases by hand in Excel: one column per input variable, one row per applicant profile, the expected outcome worked out manually for each.

Now. The analyst describes the change in a voice note, or provides the transcript of the client meeting. The agent picks the template and steps for that type of change. It writes the test cases as Python, SQL or JSON. Each case is a synthetic applicant profile: a made up applicant built to take one path through the decision tree. Each has its expected outcome: approve, refer or decline. Edge cases are placed exactly on each rule's threshold, such as a debt burden ratio (DBR) right at the cap. The profiles are loaded into the credit bureau's test database. Then Postman, a tool that sends requests to an API, calls the engine in the chosen environment to check each result. After one or two guided runs, a change request goes from received to tested in 1 to 2 hours.

The work had to stay within the banks' data privacy requirements. A model running locally, Qwen, processes everything first. It removes personally identifiable information, and any names of the bank or its products. What remains is the bare configuration logic. Only that anonymised version is sent to the cloud models, which are stronger at generating test cases.

Every run produces two outputs. An Excel workbook for the credit team lists each test case and the path it tested. It shows the expected and actual outcome, and the requirement behind it. It totals the approve, refer, decline and edge cases. A summary with charts goes to executives for their reporting. Both are stored in a front end, so every change has a record of what was tested, how, and against which requirement.

• Change request to tested: 1 to 2 hours, down from 5 or 6 working days.
• Manual checking: about 4 hours a week per analyst, down from about 16.
• Requirements reconciliation: under an hour, down from about three days.
• The BRD matches the engine again, because gaps are corrected as they are found.

The analysts' first reaction was "wow, this is amazing", mainly because the agent found the gaps and updated the document itself, work that had previously taken days. The manager asked for a demonstration to the full analyst team and the engineering team, and engineering began scoping how to build it into the decisioning software.