CASE STUDY · REGTECH / COMPLIANCE AUTOMATION
Building a real-time compliance dashboard for a multi-state lender.
01 · PROJECT OVERVIEW
The client and the brief.
An anonymised multi-state lender. Name withheld under confidentiality.
A rules engine, data feeds from the loan system and a dashboard of open issues by state. The engine held each state's rules in a structured form that compliance staff could read and update. Feeds brought loan data in daily. The dashboard listed open issues, their age, their owner and the rule behind them.
- 1Rules differed across 3 states and were tracked in spreadsheets.
- 2Each state had its own requirements for disclosures, timelines and record keeping.
- 3Compliance staff checked loan files by hand and updated the sheets.
- 4Problems were found at the quarterly review, often weeks after they happened, which made them costly to fix.
02 · WHAT WENT WRONG
What went wrong, and how we fixed it.
Every engagement hits problems. These were the ones that mattered here, and what we changed so they did not come back.
- PROBLEM 01The first run flagged hundreds of issues for one state, and compliance staff doubted the tool
The cause was a field in the loan system that used different codes for the same event in older loans. The rules read those codes literally. We built a mapping table for the old codes, reviewed a sample with staff, and re-ran.
- PROBLEM 02The count fell to a believable number, and staff trusted the tool because they had helped fix it
- PROBLEM 03A second hurdle was timing
Loan data arrived overnight, but the closing of daily batches in the loan system was not always on time. On some mornings the engine ran against half-loaded data and reported issues that did not exist. We added a completeness check that compares record counts with the source before any rules run, and the engine now waits and tells staff when a feed is late.
- PROBLEM 04A late feed is shown on the dashboard as a data issue, separate from compliance issues, so nobody mistakes one for the other
03 · THE PROCESS
How we ran it.
- 01Weeks 1 to 3
Workshops with compliance staff to convert spreadsheet logic into explicit rules. Chose a first set of high-risk rules for each of the 3 states.
- 02Weeks 4 to 7
Built the feed from the loan system, the rules engine and an early dashboard. Compared results with the latest manual review.
- 03Weeks 8 to 10
Ran in parallel with the spreadsheets, resolved differences, and trained staff.
- 04After launch
Fortnightly rule updates and a monthly review of closed and recurring issues.
04 · RESULTS
What changed.
Measured against the way the work ran before the engagement began.
- NOW 01
Compliance staff start the day with the dashboard rather than a spreadsheet.
- NOW 02
A new rule or a change in a state requirement is added in the engine, tested against past loans and approved.
- NOW 03
Managers see ageing issues by state and push owners to close them.
- NOW 04
The quarterly review has become a check of the system, not a hunt for problems.
Open compliance issues visible in one place
Issues found within a day instead of at the quarterly review
05 · WHAT WE BUILT
How it works.
- A scheduled job extracted loan and event data and loaded it into a reporting database.
- The rules engine evaluated each loan against the rules for its state and wrote the result, with the facts used, to an issues table.
- Rules were versioned, so any finding could be traced to the rule text that applied on that date.
- The dashboard read from the issues table only.
- Access was role-based: compliance staff could assign and close issues, managers could view, and every change was logged.
- Changes to rules required a second person's approval.
- Controls after launch
- Rule changes are versioned and need a second approver. Every issue records the rule version, the loan facts used and the person who closed it. A monthly report compares open issues with those closed on time, by state, and highlights rules that raise many false alarms so they can be refined.
- Handover
- Compliance staff were trained to write and test rules in the engine's structured form, using past loans as test cases. IT received documentation for the feeds, the schedule and the completeness checks. The lender's team can now respond to a new state requirement without waiting for a developer.
- Why the rules were kept readable
- We chose a structured rule format that a compliance officer can read, not code buried in the application. It cost a little more to build. It meant that when an examiner asked why a loan was flagged, staff could point to the rule text and the date it applied.
06 · QUICK ANSWERS
The short version.
- What problem did the client have?
- Rules differed across 3 states and were tracked in spreadsheets. Each state had its own requirements for disclosures, timelines and record keeping. Compliance staff checked loan files by hand and updated the sheets. Problems were found at the quarterly review, often weeks after they happened, which made them costly to fix.
- What did Brandsmashers build?
- A rules engine, data feeds from the loan system and a dashboard of open issues by state. The engine held each state's rules in a structured form that compliance staff could read and update. Feeds brought loan data in daily. The dashboard listed open issues, their age, their owner and the rule behind them.
- What were the results?
- Open compliance issues visible in one place; issues found within a day instead of at the quarterly review.
YOUR TURN
Have a similar requirement?
Tell us what is stuck. We will come back with a plan and matched, pre-vetted engineers.
