Case Study · Five Degrees (now Akkuro)

Loan management,made easy.

Five Degrees was a Dutch cloud-native core banking technology provider whose software ran at more than forty banks across Europe and North America. We helped them build their loan management platform on a team as a service engagement, working across the loan lifecycle: product configuration, origination and credit assessment, servicing and arrears, and the governed changes an agreement accumulates over thirty years. Five Degrees is now Akkuro by Topicus, and the lending products live on there.

Annual loan volume on the platform: $45BAnnual loan volume on the platform
Deposits managed on the platform: $13BDeposits managed on the platform
Assets under management: 133B+Assets under management

Engagement Overview

Five Degrees was a Dutch core banking technology provider. Not a lending startup: a vendor whose software ran inside other people’s regulated banks, more than forty of them across Europe and North America, Knab and Crédit Agricole Consumer Finance among them. Their platforms were Matrix and, from 2021, the cloud-native °neo.

Lending was real there: acquiring Libra in Iceland in 2018 brought a lending and securities suite into the portfolio, and retail and SME lending sat in what the company sold.

We built their loan management platform on a team as a service engagement, a dedicated team owning delivery rather than a ticket queue, across the whole lifecycle of a loan: the product a lender configures before any borrower exists, origination, credit assessment, servicing, arrears. Five Degrees is now Akkuro by Topicus, and the figures on the right are Akkuro’s own, not a measurement of this engagement.

$45B
Annual loan volume on the platform: $13B
Deposits managed on the platform: 133B+
Assets under management

Engagement: Team as a service
Team: Dedicated engineering team
Focus: Loan origination, servicing and lifecycle management
Working model: Owned delivery, embedded with the client

The curved glass facade of a city banking tower, its windows reflecting the buildings opposite

The Challenge

A loan is not a transaction. It is a contract that stays alive for years, sometimes for three decades, and the software has to stay correct for every day of it. Most business systems can be reasoned about in the present tense. A lending platform never gets that: every screen is a view onto an agreement with a history behind it and a schedule in front of it, and both have to reconcile.

Then the terms change, because over thirty years they always do. Early repayment, a payment holiday, the end of a fixed-rate period, a switched repayment type, a released collateral object, a restructuring after arrears. Each has to be applied to a live agreement without corrupting what came before it, and the schedule from that point on has to follow from the change rather than be retyped.

Around that sits what a regulated lender owes a supervisor: due diligence before an offer exists, a credit decision that can be defended years later, collateral and loan to value tracked for the life of the agreement, arrears recognised the day they occur, and an audit trail under all of it. And none of it could be hard-coded, because Five Degrees sold to more than forty banks rather than building for one. It had to be configuration.

The Solution

One platform, following one loan from the product a lender defines before any borrower exists to the day the agreement closes. Each section below is a stage of that life, and the order is the point: every stage inherits the record the one before it wrote, which is what makes the numbers on the last screen answerable from the first.

Platform imagery courtesy of Akkuro by Topicus, which carries the Five Degrees lending products today. The frames illustrate the capabilities described here as they appear in the product now; they are not captures of the build as we delivered it.

A configured business mortgage in the platform: two loan parts with their start dates, durations, fixed-rate periods and limits, above the arrangement fee and the borrower record

Product configuration: what a loan is allowed to be

Before a single borrower exists, a lender has to be able to say what it sells. That is the product builder, and it is the piece that decides whether the rest of the platform is a product or a bespoke build. A loan product carries its type, unsecured, secured or revolving credit, and under that a long tail of parameters: the interest model and whether it is fixed, variable or fixed for a period, the repayment type, annuity or linear or interest only, the term, the currency, the limits, the fee and penalty schedule, and the rules for what may be changed later and by whom.

Held as templates, those combinations mean a new lending product is a configuration exercise rather than a release. That matters more for a vendor than for a bank: Five Degrees sold to more than forty institutions, so a product that only existed in code would have meant forty forks of the same system. It also sets the boundary the rest of the platform enforces. Nothing downstream can produce an agreement the product definition does not allow, which is what stops configurability from becoming a way to book a loan the ledger cannot account for.

Loan Product Builder
Unsecured, Secured & Revolving
Interest & Repayment Models
Fee & Penalty Schedules

An application detail view: applicants, identification, origin and periodical payment tabs above the account information table with product, currency, duration, interest rate and IBAN

Origination: from application to signed agreement

Origination is the longest queue in lending and the one most likely to be a spreadsheet. It starts with an application and a party, and it does not finish until there is an executed agreement with money against it. In between sits the case file: the applicants and their identification, the legal structure behind a business borrower, the counterparties, the financing goal, customer due diligence and the non-consumer test, the questionnaires, and increasingly the ESG data a European lender now has to collect.

The platform carries all of that as structured state rather than as attachments, which is what lets an application have a status worth trusting. Each step knows what it is waiting on, so completeness and correctness can be checked before a case moves rather than after somebody notices. The borrower sees their side of the same record: applications in progress, agreements already live, what is outstanding and what has been asked of them, without a phone call to find out.

Application Intake
KYC & Customer Due Diligence
Case File & Statuses
Borrower Self-Service

The financial analysis screen: liquidity, interest coverage, EBITDA and debt service coverage ratios over two reporting years, with the repayment capacity calculation expanded below

Credit assessment, and being able to defend it later

Somewhere in the middle a decision gets made, and the platform's job is to make it a reasoned one that survives being asked about years afterwards. For a business borrower that means the financial statements arrive as data rather than as a PDF, and the ratios come off them: liquidity and current ratios, interest and EBITDA coverage, fixed charge coverage, debt service coverage forward and back, net working capital, and the repayment capacity that falls out of operating cash flow. For a consumer it is affordability on the same principle, computed rather than asserted.

Those feed a rating and an acceptance framework, which is where the lender's own credit policy lives as rules instead of as convention. Collateral is registered and valued, loan to value is calculated, and the whole assessment is stored with the figures it was made from. That last part is the one that is easy to skip and impossible to retrofit. A decision without the inputs it was made on is not an auditable decision, and in a supervised lender that is the difference between a credit file and a liability.

Financial Statement Analysis
Ratios, DSCR & Repayment Capacity
Rating & Acceptance Framework
Collateral & LTV

A loan overview: principal, current outstanding, collateral market value and loan to value above two loan parts, each with its repayment type, duration, next repayment date, monthly interest and an arrears amount flagged in red

Servicing: the thirty years in the middle

Once the money moves, the platform stops being a workflow and becomes a ledger with a clock attached. Disbursement, in one drawdown or in tranches against a construction deposit. The amortisation schedule generated from the product's own rules. Interest accruing daily and posting on its own cycle, principal and interest split correctly on every instalment, fees applied when they fall due. Payments matched against what was expected, and the outstanding balance, remaining term and loan to value moving with each one.

Arrears are the part that has to be structural rather than a report. The day an expected payment does not arrive, the agreement is in arrears by a specific amount, and it stays visible in that state on every screen that shows it until it is cured. That is what turns collections from a monthly reconciliation into something a lender can act on while it still matters, and it is why the arrears figure sits on the loan overview next to the balance rather than in a queue somebody has to remember to open.

Disbursement & Drawdowns
Amortisation Schedules
Interest Accrual & Payment Processing
Arrears & Collections

The loan management dashboard with a change request dialog open, listing agreement revision, arrears revision, changing the repayment type, collateral revision, construction deposit handling, early and full repayment, increasing the loan amount, interest rate revision and collateral release

Lifecycle changes: everything that goes differently

This is the chapter of a loan platform that separates the ones that work from the ones that get replaced. Over a long agreement the terms move, and each move is its own governed process rather than an edit. Agreement revision. Arrears revision. Changing the repayment type or adjusting the duration. Interest rate revision when a fixed period ends. Increasing the loan amount. Early repayment and full repayment, each with its own penalty calculation. Payment holidays. Collateral objects revised or released. Construction deposits declared, prolonged or terminated. Consolidation of several agreements into one. Write-offs.

The discipline is that a change request is applied forward, not backwards. History stays as it was recorded, the new terms take effect from their own date, and the schedule after that point is regenerated from the change rather than retyped by whoever handled it. Every one of them carries who requested it, who approved it and what it did, which is the audit trail a supervisor actually asks for. Get this wrong and a platform quietly accumulates loans whose paperwork and balances disagree.

Governed Change Requests
Interest Rate & Term Revision
Early Repayment & Payment Holidays
Restructuring & Write-Offs

The integration console: incoming reports filtered by process, counterparty and date, listed with their message types, processed and received timestamps, success statuses and per-row rerun controls, over an expanded process log

Integration and orchestration: the rest of the bank

A loan platform is never alone in the estate. It has to exchange data with payment rails and direct debit runs, credit bureaus and registries, property valuation and land registry services, identity providers, document generation, the general ledger, and the regulatory reporting nobody gets to opt out of. Each of those is a different party on a different schedule with a different definition of a failure, which is why the integration layer is a first-class part of the product rather than a folder of scripts beside it.

So the exchanges are modelled as processes with state. Every delivery and every incoming report is a run with a status, a timestamp, an external identifier and the artifacts it produced, retryable individually or in bulk when a counterparty has a bad night. On the outbound side an events hub posts what the platform did, so other applications subscribe to loan events rather than polling for them, and everything the lender needs is reachable by API as well as through the interface. What that adds up to is an audit trail: not a log file, but a record of every exchange that can be answered for.

API-First Integration
Events Hub & Subscriptions
Process Runs, Retry & Reconciliation
Audit Trail

And the rest of what a lending platform carries

None of these are stages in the life of a loan, which is why they are here rather than above. They are true of the system at every stage at once, and each one is the sort of thing that is invisible when it works and existential when it does not.

Accounts and deposits
Lending does not sit on its own in a core banking platform. Current and savings accounts, fixed-term deposits with their own rates and durations, and the money movement between them share the same party records and the same ledger the loans post to.
The ledger and accounting
Double-entry postings behind every event the platform generates, so disbursements, accruals, instalments, fees and write-offs land in the general ledger as they happen rather than being assembled from the loan book at month end.
Documents and correspondence
Offers, agreements, amendment letters, arrears notices and annual statements generated from the live record and stored against it, in the borrower's own language, so what the customer was sent is retrievable rather than reconstructed.
Reporting and supervision
An open data structure with the granularity regulatory reporting needs, plus the standard templates on top of it. A lending book that cannot be queried at the level a supervisor asks for is a compliance problem long before it is a product one.
Roles, permissions and four-eyes
Client-facing staff, credit officers, functional managers and developers each see and can do different things, with approval steps on the actions that move money or change terms, and every one of them attributable to a person.
Multi-entity and multi-currency
One deployment serving several legal entities, currencies, languages and regulatory regimes at once, which is the baseline requirement for software sold to more than forty banks rather than installed at one.

Business Impact

Five Degrees got a loan management platform they did not have to staff internally, and got it as a whole rather than in pieces. Product configuration, origination, credit assessment, servicing, arrears, the change requests and the integration layer under them sat with one team, which is why they behave as one system. Split a loan lifecycle across vendors and the seams land exactly where the money is.

Lending was part of what Five Degrees carried into its acquisition by Topicus and Total Specific Solutions in May 2023, and it is still trading. The core banking and lending products now sit inside Akkuro by Topicus, whose published figures put the platform at $45 billion in annual loan volume and $13 billion in deposits under management. Those are Akkuro’s numbers rather than ours, and we include them for the one thing they establish: the work went into a product line that outlived a change of owner and a change of name, and still carries real lending at real scale.