Overview
Every credit decisioning project starts with a business requirements document (BRD). It sets out the bank's policy rules, its risk acceptance criteria (RAC, the rules for who the bank will lend to), the input variables, the scorecards and the decision logic. The engine is configured from it, and it is meant to stay the single source of truth.
The team's documents had a loose template, but each one drifted over time. They were written by different analysts over several years, and some of those analysts had moved on. The decisions behind them were spread across client calls, internal calls, emails and files. Each analyst filed their own material in Outlook and SharePoint by hand. Pulling together one client's policy rules, scorecard cut-offs and requirements took about 6 hours.
The stages
| Stage | What it does | Status |
|---|---|---|
| 1Connect the sources | Links calls, email, SharePoint and the bank's files | Live |
| 2Pull out the decisions | Sorts each call and extracts what was agreed | Live |
| 3Guide it | The analyst steers the AI with comments and direction | Live |
| 4Fill the standard template | Pre-fills one standard requirements document | Live |
| 5Track the work | Turns the document into a checklist and a project tracker | Live |
1. Connect the sources
The requirements for one credit product sit in many places. A threshold is agreed on a client call. A change is discussed in an internal review. The bank's credit team sends an Excel sheet or a Word document. Earlier versions sit in an analyst's Outlook or on SharePoint.
The system connects to all of them. A custom note-taking app records client and internal calls and turns them into transcripts. Connectors pull in emails, SharePoint files and the documents from the bank's credit team. Everything runs through an ETL pipeline, short for extract, transform and load. It pulls data from each source, cleans it into one structure, and stores it in one place.
2. Pull out the decisions
AI classifies each call by type, such as a client requirements call, an internal review or a change request discussion. It then extracts what was decided, and what is still open. This separates firm decisions from ideas that were only discussed.
3. Guide it
The analyst works with the system rather than handing work to it. They add comments, set the direction, and say how a requirement should be read where the sources are unclear. The AI uses that guidance together with the decisions and the client's files. The analyst stays in charge of what goes into the document.
4. Fill the standard template
The system then pre-fills one standard BRD. The business version describes the credit policy, the RAC and the business needs. The technical version describes the input variables, logic formulas, decision trees and scorecards the engine needs. Both follow the same template on every project, in the format each team uses. The analyst reviews and finalises it. A standard document can also be read and updated by an AI agent, which the earlier mix of formats did not allow.
5. Track the work
The same document works as the analyst's checklist for the project. It is linked to the team's project tracker in Excel, where each deliverable shows as not started, in progress or finished. Project management sees where every project stands without asking.
Results
- About 2 hours per client to pull together the policy rules, cut-offs and requirements, down from about 6.
- A few hours to scope and start a new project, down from a few days.
- Up to 60% of the team's own manual work automated.
- One standard document on every project, so any analyst can pick up any project.



