Case study · Financial services
A collections system that cannot break the rules by accident
Collections is one of the most heavily regulated things a business can do by telephone. We built the operation on Dynamics 365 CRM so contact frequency, permitted hours and vulnerability flags are enforced by the system rather than remembered by an agent.
Engagement · Implementation & rollout
A regulated collections operation, with the rules in the system.
- Industry
- Financial services
- Solution
- Collections operations platform
- Platform
- Dynamics 365 CRM
- Engagement model
- Dedicated product team
- Scope
- Implementation, automation, reporting
- Users
- Agents, team leads, compliance
- Constraint
- Contact rules and vulnerability handling
- Audit
- Every action recorded
Outcomes
What a collections platform is measured on
Recovery matters, but a compliance breach costs more than a month of collections. Both are in the design.
-
0
Contacts outside permitted hours or frequency
The system refuses to present an account for contact when doing so would breach frequency limits or permitted hours. An agent cannot make the call, so the breach cannot happen.
By design: contact eligibility enforced before dialling
-
100%
Of actions attributable and time-stamped
Every contact attempt, promise, payment and note carries who did it and when, which is what a regulator asks for and what a complaint is resolved with.
By design: audit write on every action
-
35%
More accounts worked per agent per day
Agents work a prioritised queue the system builds rather than choosing accounts from a list, which removes the selection time and the cherry-picking.
Measured across agent activity after rollout
Context
The situation before the implementation
Why collections operations carry so much manual compliance risk.
The business
A collections operation recovering consumer and commercial debt on behalf of creditors, working by telephone, letter and digital contact.
The starting point
Accounts were worked from lists. Contact rules, permitted hours and vulnerability markers lived in a policy document and in agents' memories.
The trigger
Compliance in collections is not advisory. A single contact outside permitted hours, or one more call than the rules allow, is a reportable breach — and it was being prevented by training alone.
What they wanted
The rules enforced by the platform: accounts presented only when contact is permitted, treatment paths driven by account state, and every action recorded for audit.
Constraints
Contact frequency and permitted hours vary by jurisdiction and contact method · vulnerability markers change how an account may be treated · every action must be reconstructable years later · agents are measured on volume and will route around friction.
System
What it runs at today
The platform as it runs today.
-
4
Contact channels governed
Phone, SMS, email and letter, each with its own rules
-
1
Eligibility check
Applied before an account is ever presented
-
100%
Actions audited
Attempts, promises, payments and notes
-
0
Rules held only in training
Policy expressed as configuration
The engineering problem
Four problems in regulated collections
Every one of these is a compliance exposure before it is an efficiency question.
-
Rules enforced by training will eventually be broken
Contact frequency, permitted hours and cooling-off periods are easy to state and hard to apply consistently across hundreds of calls a day. A breach is one tired agent away.
What we did
Eligibility is computed before an account is offered. If contact would breach a rule, the account is simply not in the queue — there is no decision for the agent to get wrong.
-
Vulnerability changes everything and must not be missed
A vulnerability marker alters permitted treatment entirely. If it sits in a note somebody has to read, it will occasionally be missed, and that is the failure that ends up in a regulator's report.
What we did
Vulnerability held as structured state on the account, driving eligibility and treatment path automatically rather than relying on an agent noticing a note.
-
Cherry-picking distorts recovery and fairness
Given a list, agents work the accounts most likely to pay. That skews recovery statistics and treats otherwise identical customers differently.
What we did
Queues built by the system on account state and treatment stage, so the next account is presented rather than chosen.
-
A complaint two years later needs a reconstructable record
Collections complaints arrive long after the fact. Without a complete timeline, the operation cannot defend itself even when it behaved correctly.
What we did
Every action written to an append-only audit with who, what and when, so a full account timeline can be produced from the system.
Architecture
How it fits together
Simplified — the shape of the system rather than every service in it.
-
Account model
- Debt records
- Treatment stage
- Vulnerability state
The account as a structured record whose state drives what may happen to it, rather than a row with notes attached.
-
Eligibility engine
- Frequency rules
- Permitted hours
- Cooling-off
- Vulnerability
Computed before presentation. The rules are configuration, so a jurisdictional change is a setting rather than a release.
-
Queues & treatment
- Prioritised queues
- Treatment paths
- Channel selection
The system decides what is worked next and through which channel, based on stage and eligibility.
-
Audit & reporting
- Append-only audit
- Complaint timelines
- Regulatory reporting
A complete, attributable history, designed to be produced for a regulator rather than searched through.
The eligibility engine sits in front of everything. Nothing reaches an agent without passing it, which is the difference between a system that supports compliance and one that enforces it.
Solutions
What we implemented
A collections platform where the rules are part of the machinery.
-
Account model
Debt, stage and vulnerability as structured state driving what may happen.
-
Eligibility engine
Frequency, hours, cooling-off and vulnerability checked before presentation.
-
Treatment paths
Stage-driven channel and approach, applied consistently.
-
Agent queues
The next permitted account presented rather than selected.
-
Promises & payments
Arrangements tracked, with breaks driving the next stage automatically.
-
Audit & reporting
Append-only history and regulator-ready account timelines.
Key capabilities
What it does day to day
Six capabilities across the collections cycle.
| Capability | Runs | Refresh | What it does |
|---|---|---|---|
| Account records | System | Continuous | Debt, balance, treatment stage and vulnerability state in one record |
| Eligibility | Automatic | Before presentation | Frequency, hours, cooling-off and vulnerability checked before an account is offered |
| Prioritised queues | Automatic | Continuous | The next account presented by stage and priority, not chosen by the agent |
| Treatment paths | Automatic | Per stage | Channel and approach driven by account state rather than agent preference |
| Promises & payments | Agent | Per contact | Arrangements recorded and monitored, with breaks driving the next stage |
| Audit trail | Automatic | Per action | Append-only record of every attempt, contact and change |
Integrations
How the moving parts plug in
No account reaches an agent without passing the rules.
Account state
- Balance & stageWhere the account is
- Contact historyWhat has already happened
- VulnerabilityStructured, not a note
Eligibility engine
- Frequency limitsPer channel
- Permitted hoursPer jurisdiction
- Cooling-off & vulnerabilityApplied automatically
Agent queue
- Next account
- Permitted channel
- Treatment guidance
Because eligibility runs before presentation rather than as a warning at dial time, the operation can state that a non-compliant contact was not possible rather than that it was discouraged.
Security & data
What protects consumers and the operation
In collections the compliance controls and the data controls are the same conversation.
-
Rules as configuration
Contact rules are held as data, so a regulatory change is applied by configuration and takes effect immediately across every queue.
-
Append-only audit
Actions can be added but never quietly amended, so a historical timeline can be relied on.
-
Vulnerability handling
Vulnerability state drives treatment automatically and is visible to every agent who touches the account.
-
Role separation
Agents, team leads and compliance have distinct rights, with the ability to change rules restricted to compliance.
The brief
In collections, the compliance design is the product design
It is possible to build a collections system that is efficient and non-compliant, and it is possible to build one so cautious that nothing gets recovered. The work is in making the compliant path also the fastest one.
We did that by computing eligibility before an account is ever presented, so the agent's quickest route is always the permitted one.
- Eligibility computed before presentation
- Vulnerability as structured state, not a note
- Queues built by the system, not chosen by agents
- An append-only record for every action
What the platform had to respect
- 01Contact rules that vary by jurisdiction and channel
- 02Vulnerability markers that change permitted treatment
- 03Agents measured on volume, who will route around friction
- 04Complaints arriving years after the contact
Process
We built the eligibility engine first
Everything else in a collections system is downstream of what an agent is allowed to do.
-
Capturing the rules
Working through every contact rule with the compliance team, including the ones that only existed in a policy document nobody had opened recently.
-
Eligibility engine
Built and tested against historical contact data to confirm it would have prevented the breaches that had occurred.
-
Account and treatment model
Stages, transitions and channel rules expressed as configuration rather than code.
-
Queue and agent experience
Designed so the permitted action is also the fastest, tested with agents before rollout.
-
Audit and reporting
Complaint timelines produced for real historical cases and checked with compliance before go-live.
Technology
Dynamics 365 with the rules held as data
A regulatory change should be a configuration change, not a development project.
CRM
- Dynamics 365 CRM
- Custom entities
- Business process flows
Rules
- Eligibility configuration
- Jurisdiction rules
- Vulnerability handling
Automation
- Queue building
- Treatment progression
- Promise monitoring
Audit
- Append-only log
- Account timelines
- Regulatory reporting
Business impact
What changed for the operation
Three things the business and its compliance team noticed.
-
Breaches became structurally impossible
The rules are enforced before presentation rather than trained into agents, which changes the risk profile entirely.
-
More accounts worked, fairly
System-built queues removed both selection time and cherry-picking.
-
Complaints answered from the record
A full timeline is produced from the system rather than reconstructed from notes.
The result
The compliant path is also the fastest path
Accounts reach agents only when contact is permitted, treatment follows the account's state rather than an agent's preference, and every action is recorded in a form a regulator can read.
Agents work more accounts per day because the system removes the selection step, not because anyone is cutting corners.
- Contact rules enforced before presentation
- Vulnerability driving treatment automatically
- System-built queues removing cherry-picking
- Append-only audit supporting complaints years later
What we hold to in regulated operations
- 01Enforce before the action, do not warn during it
- 02Hold the rules as configuration so changes take effect immediately
- 03Test the rules against the breaches that already happened
- 04Make the compliant path the path of least resistance
Verified reviews
What clients say about our Dynamics work
Verified reviews from clients of ours on similar work, published on Clutch. They are not from this project.
-
Custom Software Development
Web-Based Coupon App Development
The work produced by the team was of exceptional quality.
Jon Thies
CTO, Model Rocket Feb 2022 – Mar 2023
-
Custom Software Development
Mobile & Web Platform Development & Design
Silver Scintilla was responsive, respectful, and enjoyable to work with, quickly addressing any questions or requests.
DeShawn Brown
CEO & Founder, Lithios Jun 2021 – Nov 2022
-
Custom Software Development
Web-Based HRM System Development
Silver Scintilla provided the best solution with scalable functionality, personalized features, and robust security.
Suheb Khan
Director, Collaborative Insight Technologies Jul 2020 – Jun 2022
Free discovery call
Have an idea? Let's turn it into AI-powered software.
Book a free discovery call with our experts. Share your idea and we will help you shape the scope, timeline and budget, under NDA.
- Free consultation
- NDA before we talk
- Transparent estimate