How to choose a collections and recoveries system in 2026

What should a collections and recoveries system do in 2026?

A collections and recoveries system in 2026 needs to support the end-to-end management and resolution of customers in financial difficulty. At a minimum, it should:

• manage the customer journey across every channel, including digital self-service;
• record and manage arrangements and resolution outcomes, including promises to pay, payment plans, settlements and other appropriate routes to resolution;
• make and record decisions in real time, so treatment is driven by current data rather than last night's batch;
• manage workflow, exceptions and case activity, including where manual intervention or specialist support is required;
• hold the evidence required for oversight and regulatory assurance, including affordability and vulnerability handling, customer-outcome monitoring and, in the UK, Consumer Duty evidence; and
• connect to the wider technology and data estate through APIs, rather than relying on file transfers.

Much of this is now table stakes. Digital self-service, configurable customer journeys, robust audit trails, open integration and the ability to evidence customer outcomes should now be expected of a modern collections and recoveries platform and tested in every RFP. What remains relatively rare is real-time orchestration across every channel, combined with explainable AI, effective model governance and the ability for the business to make changes without substantial vendor support. Those are the capabilities that separate the shortlist, and every selection arum runs now scores vendors on AI governance and explainability alongside functional fit. Where AI is used, the question is not simply what it can do, but whether its decisions can be understood, governed and evidenced appropriately.

Upgrade, buy or build: how do you decide?

There are four routes, not two. You can buy an off-the-shelf collections platform; build natively in-house; customise a developable platform; or build around a CRM or account-management platform such as Salesforce or Appian. Most organisations buy. Building can be a credible option, but the time, cost and ongoing ownership required to replicate specialist collections capability can easily be underestimated. The right answer depends on your operating model as much as your budget: who will change the system next year, and how fast?

My rule of thumb on the upgrade question is to treat a major upgrade as a competitive decision, not as the default. If the incumbent can close the capability and architecture gaps with materially less cost, risk and disruption, upgrading may still be the right answer. But a major upgrade of an enterprise collections system typically takes nine to eighteen months, and a new implementation often falls in the same range, so the incumbent should compete for the work like anyone else. Testing the wider market gives you confidence you are making the right decision and creates competitive tension, which can also lead to more favourable commercial terms from the incumbent. Contract renewal is the moment with real leverage, and most organizations spend it on price alone.

How do you write requirements that vendors can price?

Requirements are a business exercise that technology then serves, and they have to exist before the vendor conversation, not during it. The pattern arum sees most often is a preferred vendor chosen on a few conversations, a contract signed under time pressure, and requirements left to be "figured out during the project". The vendor then needs detailed processes to configure against, the team does not have them, the project slips a week, then three, and the first change requests arrive for things everyone assumed were in scope.

A requirement a vendor can price describes an outcome in your business terms, names the data it depends on, and says how you will know it works. A poor requirement is: "The system must support vulnerable customers." A stronger version is: "The system must allow authorised users to record vulnerability indicators, support needs, consent and reasonable adjustments; use that information to alter treatment and communications; trigger appropriate referrals and reviews; and retain a complete audit trail for reporting and assurance." The first cannot be priced or tested. The second can be both, and the difference decides whether your fixed-price quote survives contact with the build.

How do you shortlist from the whole market?

arum's model runs in five steps: map the global market against your agreed requirements, not only the vendors you know; assess a longlist and shortlist on functional, technical, operational and delivery fit; validate the shortlist with scenario-based demonstrations, references and due diligence, scoring every vendor against weighted requirements; select on fit to requirements, business case and delivery needs; then negotiate.

The market is wider than most buyers think. Marketplace by arum tracks 191 vendors and arum has evaluated 47 AI providers worldwide. Twelve platforms carry the arum approved mark, which means they have passed an independent assessment across 20 capability areas. That is useful evidence, but it never sets the shortlist. Your requirements do.

How do you run demo days that tell you something?

A demo day is an evaluation, not a showcase, and it is the stage where teams ease off just as the decision is being made. arum has supported more than 35 major selections and sat in hundreds of demo days. Eight things separate a useful day from a polished one: give each vendor a full day; prepare detailed real-world scenarios covering your most complex processes and share them in advance; insist on live demonstrations, never slides; set scoring criteria before the first demo; put the vendor's real implementation team in the room, not the sales team; cover non-functional requirements such as hosting, resilience and security; involve frontline users and take their feedback seriously; and keep the business case in view throughout.

The one thing I ask every vendor to show, and most would rather not, is a complex exception journey, live, from the initial customer event through decisioning, workflow, communication, manual intervention and audit trail. The test is not whether the happy path works. It is what happens when data is missing, a rule fails, or a customer needs to move outside the standard journey.

What does a collections system cost, and what is left out of the quote?

The licence is the number everyone quotes and rarely the largest. The full cost of ownership includes implementation and configuration, integration with your existing estate, data migration and cleansing, testing, training, hosting and service levels, post-go-live support, and your own people's time for the duration. Vendors often present pricing in bundles; the work is to unpack what is included (configuration, testing, training) and what is not (custom development, post-go-live support), because every ambiguity becomes a change request later.

The cost most often understated is the client's own delivery capacity: the subject-matter experts, data teams, testers and operational colleagues needed throughout design, migration, testing and implementation, including the cost of backfilling their day-to-day roles. For a US financial services provider, arum ran a pre-implementation review with a total cost of ownership model, contract risk review and benchmark service levels before the programme started, which is the point at which the numbers can still change the decision.

How long does a system selection take?

With clear governance, available stakeholders and an established methodology, a full selection can be completed in around ten weeks. arum ran one for a consumer credit organisation that needed to handle rising volumes and onboard acquired portfolios: shortlisting, RFI and RFP, scenario demo workshops and a final recommendation, aligned to the client's target operating model. The plan had allowed six months. The method draws on working knowledge of more than 30 collections systems, which removes the research time most selections spend learning the market from scratch.

Selections usually slow down because internal decisions and inputs are not ready: the operating model is unresolved, requirements keep changing, stakeholders are unavailable, or procurement, security, legal and architecture reviews begin too late. The vendor timetable is rarely the only constraint.

What goes wrong after signature?

The contract defines not just what the vendor delivers but how, and misunderstandings settled at signature are cheap in a way they are not six months into the build. Seven things are worth arguing about before you sign: a scope that is tied to the detailed requirements; fixed-price deliverables wherever the scope is tight enough to allow them; the pricing model and exactly what sits inside it; hosting and service levels matched to your real volumes and resilience needs; the ongoing service model and who owns configuration after go-live; the line between configuration and customisation, which is where cost and risk hide; and the time to do all of this properly now rather than pay for it later.

The clause I insist on is contractual traceability from the agreed requirements through to the deliverables and acceptance criteria, with clear responsibility for resolving anything that does not meet them. Without that link, an apparently fixed-price contract can still leave substantial scope open to interpretation and change control.

Next step

If you are weighing a selection, or a renewal that deserves one, talk to Matt. Thirty minutes with one of arum's senior experts: the market seen clearly, the right options compared, and the commercial terms got right. Book a conversation.