A core banking system conversion moves a bank's accounts, balances and product set-up from one platform to another, and on the lending side the part that goes wrong is rarely the balances. Balances reconcile, because everyone checks them. What does not reconcile is the static data behind each loan — the index, the fixing date, the floor, the margin, the day count, the fee base — because there is nothing on the new system to compare it with except the agreement in the file, and nobody reads the agreement again. Botminds' Loan Interest & Fee Calculation is built to read it again: it rebuilds each loan's next bill from the signed agreement and the published rates, and sets every pricing term against what the core system was actually set up to do.
What follows uses a fictional sample bank inside the solution, with invented borrowers and demo figures. The supervisory and market material is the Federal Reserve's, the OCC's and the ARRC's, linked where it appears.
One conversion batch, read again six months later
38loans
converted into the core loan system on the same day, 3 April
12terms
pricing and fee terms read from each agreement and set against the system
2
loans whose set-up differed from their notes; the other 36 agreed
$3,875.75
overbilled on the two in the third-quarter run alone, before any earlier quarter is counted
What breaks in a core banking system conversion?
Three things, in rising order of how long they stay hidden. Balances and accruals break first and are found first, because the reconciliation is built before go-live and somebody owns the variance. Interfaces break next — a feed that does not arrive, a file in the wrong layout — and they break loudly. Static data breaks last, or rather it does not break at all: it is simply set to something, and the something is only wrong relative to a document that the conversion never read.
The reason static data is different is worth being precise about. A wrong balance is wrong against another number the bank already holds. A wrong day count is wrong against a sentence in a credit agreement, sitting in a file, which no automated comparison touches. The new system will compute perfectly well on it. So will the next one. The only thing that makes it visible is somebody reading the clause and the set-up side by side.
Static data: the fields that decide the bill
On a commercial loan, about a dozen fields decide what the borrower is billed. Each is set once — at boarding, or again at conversion — from a human reading of the agreement, and each has a plausible wrong value that will not look wrong on any screen.
Twelve terms set at boarding or conversion, and where each is written
The index
Where it is writtenThe definition of the benchmark in the agreement
What goes wrongTerm SOFR, daily simple SOFR, a SOFR average or prime — each a different rate on the same day.
The tenor
Where it is writtenThe same definition, usually in the same sentence
What goes wrongOne-month against three-month is a basis difference on every bill, not a rounding one.
The fixing date
Where it is writtenThe benchmark definition
What goes wrongTwo U.S. Government Securities Business Days before the period, on the sample loan. A day out is a different published rate.
The floor
Where it is writtenA proviso inside the benchmark definition
What goes wrongWhether it applies to the index alone or to the index plus the margin, and whether it is tested daily or per period.
The margin
Where it is writtenThe interest clause, or a pricing grid
What goes wrongA grid that steps with leverage or coverage has to move when the certificate arrives, and often does not.
The day count
Where it is writtenThe computation-of-interest clause
What goes wrongThe sample agreement gives 30/360 for the term loan and Actual/360 for everything else, in one sentence.
The amortization
Where it is writtenThe repayment clause
What goes wrongAmount, dates and whether the instalment is applied before or after interest is accrued for the period.
The fees
Where it is writtenThe fee clauses
What goes wrongRate, base and whether letters of credit count as usage. The base goes wrong more easily than the rate.
The default rate
Where it is writtenThe default interest clause, with the notice clause behind it
What goes wrongThe increment, what it applies to, and the date it starts — which is a notice question, not a rate question.
The payment dates
Where it is writtenThe interest payment clause
What goes wrongPeriod ends, the business day convention and whether interest is paid in arrears or in advance.
The rounding
Where it is writtenUsually nowhere
What goes wrongWhere the agreement is silent the system’s default becomes the term. It should be a written setting with a version behind it.
The calendar
Where it is writtenThe business day definition
What goes wrongWhich holidays close the market for the benchmark, and which merely move a payment.
Two of those twelve deserve a second look at conversion specifically. The rounding row is the one with no clause behind it: where the agreement is silent, whatever the old system did became the term the borrower has been billed on for years, and the new system's default may differ. And the floor row is the one most often carried across as a number rather than as a rule — 0.50% copied into a field, with the question of whether it applies to the index alone or to the index plus the margin left behind in the old platform's configuration.
Why a conversion error arrives as a batch, not as an incident
An incident has one victim and a start time. A conversion defect has neither. Loans do not convert one at a time; they move in batches, mapped by the same rule, loaded on the same day, checked by the same sample. If one loan in the batch has the wrong day count, the interesting question is never "what did this cost" but "how many others were loaded with it".
That changes what a test has to prove. Sampling a conversion the way an auditor samples a population is the wrong shape, because the errors are not randomly distributed — they are perfectly correlated within whatever grouping the mapping used. Twenty loans sampled from five hundred will either all miss a mapping fault or all sit inside it, depending on which batch they came from. The only test that answers the question is the whole batch.
It also changes the arithmetic of the remediation. The restitution is not the error times one loan; it is the error times every loan in the batch, times every billing period since go-live. A six-month-old conversion with quarterly billing has already produced two wrong bills per loan, and the second was paid.
What the LIBOR transition taught about converting loan terms in bulk
The LIBOR transition was a conversion of static data across an entire market, and the ARRC said in advance where the operational risk sat — not in the rate, but in the fields describing it.
the unstructured, non-standardized nature of the data will likely increase the operational risk of the transition (e.g. static data not being updated correctly, leading to incorrect coupon accruals and reconciliation differences).
Alternative Reference Rates Committee, LIBOR Legacy Playbook, 2022 (Federal Reserve Bank of New York)
Two phrases carry the lesson. Static data not being updated correctly is the mechanism: a field, changed by hand, from an unstructured source. Incorrect coupon accruals is the consequence, which is a billing error by another name — and one that compounds quietly, because an accrual is not checked against anything.
Where a contract had no workable fallback at all, Congress and the Federal Reserve supplied one. Regulation ZZ records the point of the statute: the purposes of the Adjustable Interest Rate (LIBOR) Act are "to establish a clear and uniform process, on a nationwide basis, for replacing the overnight and one-, three-, six-, and 12-month tenors of U.S. dollar LIBOR in existing contracts that do not provide for the use of a clearly defined or practicable replacement benchmark rate." A uniform legal process does not, however, set a field on a servicing platform. Somebody still had to do that, loan by loan.
The replacement rate itself is a conversion choice with consequences the servicing desk inherits. The ARRC supports "the use of SOFR Term Rate in addition to other forms of SOFR for business loan activity—particularly multi-lender facilities, middle market loans, and trade finance loans—where transitioning from LIBOR to an overnight rate has been difficult," while adding that "it continues to recommend use of overnight SOFR and SOFR averages for all products." A book converted to Term SOFR, as many commercial loans were, therefore carries a fixing date, a tenor and a lookback that overnight SOFR simply does not have — three more static fields per loan, each set once, each able to be set wrong. What each of them means on a bill is set out in the fixing date, the floor and the margin.
How do you test loan data after a conversion?
Not by comparing the new system with the old one. That test is seductive, cheap and nearly worthless: it proves the conversion moved what was there, which is only reassuring if what was there was right. Any term that was wrong before go-live passes a system-to-system comparison perfectly, and the conversion inherits an error it did not make and now owns.
The test that works compares the system with the agreement. Concretely: for each converted loan, read the pricing and fee terms out of the signed agreement and every amendment, rebuild the next bill from them and from the published rate fixings, and compare that bill with the one the core system produces. A difference means one of the two is wrong, and the difference itself points at which term.
The OCC's internal control booklet states the general principle in a line worth quoting to a programme board: "Bank employees should enter pertinent information into processing systems in a timely manner, and appropriate bank personnel should independently test that information for accuracy." The word carrying the weight is independently. A test that reads the same field the conversion wrote, from the same mapping document the conversion used, is not independent of it. The agreement is the only independent source there is.
Examiners use the same move when they do not trust a source. The OCC's lending booklet notes that "examiners may use transaction testing to verify the accuracy of bank reports, validate the results of credit risk reviews, or form conclusions about underwriting when bank sources are not reliable." After a conversion, the bank's own set-up is precisely a source whose reliability is the open question.
Reading the agreement again: twelve terms, one that differs
Here is what that looks like on one loan. Kestrel Ridge Foods, Inc., Loan 4471 — a term loan and a $15,000,000 revolving line under an amended and restated credit agreement dated 3 April 2026, converted into the core loan system the same day. The solution reads twelve pricing and fee terms out of the agreement, each with its clause, and sets them against the system's set-up.
Eleven match. The rate is 6.20% fixed under §2.4(a), in both. The amortization is $187,500.00 quarterly under §2.3, in both. The revolving index is Term SOFR one-month, the fixing date is two U.S. Government Securities Business Days before the period, the floor is 0.50% and the Applicable Margin is 2.35%, all under §1.1 and §2.4(b), in both. The revolving day count is Actual/360 in both, and the unused line fee's rate and base, with letters of credit counting as usage, agree in both.
One differs. Section 2.4(c) says interest on the term loan is computed on a 360-day year of twelve 30-day months; the core system has billed it on a 365/360 basis since the conversion. One sentence of one clause, one field, and every quarterly bill on that loan has been wrong since April — by $1,378.07 in the second quarter, paid on 1 July, and $2,691.55 in the third. The arithmetic of that particular difference is worked through in what the 365/360 method costs a borrower.
Twelve terms read from the agreement, set against the system's set-up
From conversion to correction: 181 days, two of them wrong bills
- Converted 3 April; first quarter on the new set-up89 days
- Q2 bill paid 1 July, $1,378.07 over; Q3 accrues on the same set-up92 days
The sweep: finding every loan that converted on the same day
One wrong loan is a correction. The question that decides the size of the problem is what else came through with it, and the only way to answer it is to read the batch. The solution's distinctive move is exactly that: having found the day count wrong on Loan 4471, it read all thirty-eight notes converted on 3 April and compared each one with its set-up.
The 3 April batch, read again: thirty-eight notes, two that disagree
| Loan | Borrower and product | What differs | This quarter |
|---|---|---|---|
| 4471 | Kestrel Ridge Foods, Inc. · term loan and revolving line | Term loan billed 365/360; the note gives 30/360 | $2,691.55 over, plus $1,378.07 already paid for Q2 |
| 5208 | Marlowe Street Partners LP · commercial real estate term loan | The same wrong basis: 92 days billed where the note gives 90 | $1,184.20 over |
| The other 36 | Every other note converted on 3 April | Nothing — each agreed with its set-up on all twelve terms | $0.00 |
The thirty-six are not a footnote. They are the answer to the question an auditor will ask first and a borrower's counsel will ask second, and a bank that cannot produce them has only unattractive options — refund a batch it has not examined, or record that it did not look. What a wrong bill costs once the batch is counted is set out in what one wrong loan bill costs a bank.
The grouping to sweep is whatever the mapping used, and it is usually not just a date. Loans converted on the same day, loans of the same product code, loans whose old platform held the same value in the same field, loans boarded by the same team in the same week. A sweep that only follows the conversion date will miss a fault that followed a product code, and vice versa.
Proposing a set-up change without changing the system yourself
A check that writes to the core system is not a check; it is a second source of errors with no one to catch it. The discipline that makes this work in a bank is that the finding and the change are separate acts with separate owners. The agents propose the set-up change, with the clause and the arithmetic attached. A loan operations supervisor approves it. Loan operations applies it in the core system. Every change to the servicing rules themselves is saved as a new version, so the settings in force on any past billing date can be recovered.
The same separation decides who signs the money. In the sample bank the servicing officer signs credits up to $2,500, and above that the loan operations supervisor co-signs — which is why Kestrel Ridge's $4,069.62 credit, being the two quarters together, went to a second signature along with the day-count change on both loans.
The servicing rules a bank owns, and the version history behind them
A readiness list for the first billing run after go-live
Most conversion test plans are written around balances and interfaces, and the loan-terms work arrives as a line item called "static data validation" with no method under it. These are the ten checks we would want evidence for before the first run, each answerable with the bank's own files.
Ten checks before the first billing run after conversion
- Rebuild every converted loan’s first bill from its agreement, not from the old system.
A system-to-system comparison inherits every error the old platform already had.
- Know your batches before you test, not after.
Conversion date, product code, source field, loading team. The sweep you can run decides the finding you can bound.
- Check the day count separately for each facility on a loan.
One agreement commonly gives 30/360 for a term loan and Actual/360 for the revolver and the fees, in a single sentence.
- Check the floor as a rule, not as a number.
Whether it applies to the index alone or to the index plus the margin, and whether it is tested daily or once per period.
- Check the fee base, not just the fee rate.
Whether letters of credit count as usage, and whether the base is the average daily unused amount or a period-end figure.
- Check every pricing grid against the latest certificate.
A margin that steps with leverage has to move when the certificate arrives; conversions tend to freeze it at the value in force on go-live day.
- Check the fixing date and the calendar together.
Two business days before the period is only meaningful once the business day definition is the right one.
- Decide the rounding rule explicitly where the agreement is silent.
Otherwise the new platform’s default silently becomes a term the borrower has not agreed and the old platform did not apply.
- Set the tolerance and the hold rule before go-live, and write down who may release a held bill.
A threshold decided during a late run is a threshold set by the deadline.
- Keep the first run’s evidence: which terms were read, from which agreement version, against which set-up.
This is what lets a bank answer, two years later, how far back a fault reached — without re-running anything.
The last one is the one programmes skip, and the one that costs most later. A conversion produces an enormous amount of evidence and keeps almost none of it, because the evidence was made to get to go-live rather than to answer a question in 2029. Keeping what was read, from which version, against which set-up turns a future enquiry into a lookup. How to test the same thing when you are buying rather than converting is set out in testing a servicing system on bills you already sent.
Questions people ask
What is a core banking system conversion?
Moving a bank's accounts, balances and product set-up from one core platform to another, usually in waves by product and portfolio. On the lending side it includes re-creating each loan's static data — index, tenor, fixing date, floor, margin, day count, amortization, fees, default rate, payment dates — on the new system, which is where the billing risk sits.
What static data is set when a loan is boarded or converted?
About a dozen fields decide what the borrower is billed: the benchmark and its tenor, the fixing date, any floor and how it is applied, the margin or pricing grid, the day-count basis for each facility, the amortization amount and dates, each fee's rate and base, the default rate and what triggers it, the payment dates and business day convention, the rounding rule, and the holiday calendar.
How long after a conversion do billing errors show up?
On a quarterly-billed commercial book, the first wrong bill goes out at the first period end after go-live, and is usually paid. Discovery depends entirely on who is looking: without an independent recalculation it waits for a borrower's controller, which on the sample loan would have meant at least two paid quarters. With one, it is caught before the bill is sent.
How do you find every loan affected by the same set-up error?
By rebuilding the bills for the whole grouping the mapping used, not by sampling. Find the batches first — conversion date, product code, source field, loading team — then read each loan's agreement against its set-up across that batch. On the sample bank that meant all thirty-eight notes converted on 3 April; two differed and thirty-six did not.
Who signs off a loan set-up change after a conversion?
The separation that matters is that whoever finds the difference does not apply it. In the sample solution the agents propose the change with the clause and the arithmetic attached, a loan operations supervisor approves it, and loan operations applies it in the core system; every change to the servicing rules is saved as a new version so past billing dates can be reconstructed.
Does testing against the old system count as a test?
Only for the conversion itself. It proves the data moved intact, which is worth knowing, but any term that was already wrong on the old platform will match perfectly and pass. The only test that can find a pre-existing error is a comparison with the signed agreement, which is also the only source independent of both systems.