Affordability checks should be straightforward.

In most cases, the logic is simple. A lender or tenant referencing firm sets an income threshold and must confirm whether the applicant’s verified income meets it. If it does, the application can proceed. If it does not, additional checks or alternative options such as reallocation of rent across a household or joint applicants may be required.

The difficulty is not the affordability logic itself. The difficulty is how organisations operationalise income verification.

Today, most affordability programmes are built around a combination of different verification methods and vendors. A typical stack might include an Open Banking provider, document uploads such as payslips (sometimes with fraud forensics), automated or manual employment references, or credit bureau services such as CATO (Current Account Turnover). Each of these tools addresses a slightly different question and has its own workflow and integration requirements.

The common thread is that most of these vendors optimise for data availability. Success is often measured by whether a data source is connected and data can be retrieved. But this is not the outcome businesses actually care about. The real question is whether the applicant’s income meets the affordability requirement.

This misalignment becomes particularly visible with Open Banking. It is a powerful way to access transaction data and identify income signals, but connection success does not guarantee a usable affordability outcome. Industry data indicate that Open Banking connection rates typically range from 40 to 90 per cent. Of those successful connections, only about 60 percent contain transaction histories that are actually sufficient to assess affordability - which is the whole point.

In practice, this means that a large proportion of applicants still require additional steps. If data returned from a source is incomplete or inconclusive, operations teams often need to review transactions manually or request supporting documents, such as payslips. If that fails, the process moves to an alternative verification method.

Over time, affordability programmes become a collection of siloed fallback workflows.

One source connects, but requires manual review. Another source fails, triggering document collection. A third, like Konfir, may provide a payroll record that finally confirms the income requirement. Each step may involve a different vendor, a different workflow, and a different integration. It is not uncommon for organisations to rely on two or three separate verification providers to cover these scenarios.

The result is a fragmented affordability process that is expensive to maintain, difficult to optimise, and often slower than applicants expect. Operations teams spend time interpreting raw data, reviewing transactions, or chasing documents instead of receiving a clear affordability outcome.

The core problem is not the affordability model itself. The problem is that most income verification tools are designed to retrieve data from a single source rather than confirm whether the affordability requirement has been met.

A more effective approach starts with the outcome rather than the data source. Instead of asking whether a particular source can return data, the verification process should answer the question the client actually needs to resolve: does the applicant’s verified income meet the required threshold?

Want to find out more about how Konfir can speed up your income verification process? Book a quick no-obligation demo here.