Last updated: September 23, 2026
A single source of truth is one canonical record for each borrower, policy, or claim, with a validation library that says which fields are trusted and an uncertainty tag on every field that isn’t. It describes the records rather than any tool, so you can check whether you have one this week.
$41.2 million. $38.9 million. $44.0 million.
Those were the three answers a fund produced, inside one afternoon, to one question from the lender on its back-leverage facility. What is your exposure to this borrower? I’ll call the borrower Harlow Logistics, which is not its name.
The loan system said $41.2 million, because it carried the whole facility the fund had agented. The administrator said $38.9 million, because it booked only the fund’s share after a participation went to a sister vehicle in the spring. The covenant workbook said $44.0 million, because an analyst had added the undrawn delayed-draw tranche two years earlier to test leverage headroom, and nobody took it back out.
Every number was correct for the question its system was built to answer. None of them answered the lender’s.
Two people spent most of a day producing a fourth figure everyone could sign, and the next morning the three systems still disagreed, because nothing about the fix had been written anywhere a machine could read. The reconciliation was still done by hand. It would be done by hand again next quarter.
That afternoon is what people mean when they ask for a single source of truth. They rarely mean a new warehouse. They mean they would like to answer the question once, and get the same number the second time somebody asks.
KORE1 hosts my writing and runs a data engineering and data science staffing practice that places many of the people who build what I describe below, so weigh the staffing section with that in mind. Nothing here requires software you don’t already own.
What the Phrase Should Mean in a Credit Fund
In a lending or insurance business, a single source of truth is a set of canonical records keyed at an agreed grain, one per borrower, policy, or claim, where every field has a named authority, passes a written set of checks, and says plainly when it can’t be trusted yet. That’s my working definition of a data foundation.
Most definitions you’ll find online stop at the first half. One place for the data. That’s storage, and storage was never the scarce thing.
Three parts, then, and the question each one answers.
| Part | The question it answers | What you can hold in your hand | What happens without it |
|---|---|---|---|
| Canonical record | Which borrower is this, and at what grain? | A key, a field list, and a named authority for every field | Three correct numbers for one question |
| Validation library | Is this field trusted? | Written rules that run without a model, such as tie-outs, ranges, and cross-system checks | Trust by reputation, usually one analyst’s |
| Uncertainty tag | What can’t we support yet, and why? | A state and a reason on every field that failed a rule or couldn’t be read | Blanks that quietly become zeros |
Order matters. A tag with no library behind it is an opinion, and a library with no agreed record has nothing to check, so build them top to bottom. The same order runs through the six steps of the document-to-decision method, where the canonical schema comes second and the rules third, before any model sees a page.
The Grain Decision Nobody Schedules
Harlow Logistics was three numbers because nobody had decided what a borrower is.
That sounds like philosophy until you notice it’s a database key. The loan system keyed on the facility, the administrator on the fund’s position, and the covenant workbook on whatever the analyst needed that quarter. Each grain was defensible on its own terms. The trouble was that no document anywhere said which one the firm used when a lender, an LP, or a credit committee asked about exposure, so every department answered at its own grain and nobody noticed until the answers had to agree in front of someone outside the building.
So the first artifact is a sentence.
Something like “Exposure to a borrower is our funded share of every facility where the obligor or a guarantor sits in the same ownership group, measured at the administrator’s month-end close.” You can argue with that sentence. You should. An argument about a written sentence takes an hour, and the same argument conducted through three spreadsheets takes a quarter.
Ownership group is where it gets hard. One sponsor can appear as a holdco, two opcos, and a new borrower entity formed for an add-on acquisition, and your systems will spell all four differently. Resolving them into one group is its own discipline, entity resolution, and it deserves a separate piece. Colin Boothe has written the customer-and-vendor version of the same problem in his guide to AI data cleaning.
There is a public anchor for some of it. The Legal Entity Identifier, administered by GLEIF under the ISO 17442 standard, is a 20-character code that can only ever represent one entity, and it links to ownership data so that it answers what GLEIF calls “who is who” and “who owns whom.” Where a borrower has one, key to it. Plenty of private middle-market borrowers never had a reason to register, so most funds carry their own key and map to the LEI where one exists.
Banks Were Told to Do This in 2013
The largest banks in the world have had this in supervisory guidance for more than a decade.
The Basel Committee’s BCBS 239 principles for risk data aggregation, published in January 2013, ask banks to build integrated data taxonomies using “single identifiers and/or unified naming conventions for data including legal entities, counterparties, customers and accounts.” A later principle asks them to work toward a single authoritative source for risk data of each type. Key, grain, authority. Same three ideas, in a supervisory document.
Then look at how it went. In November 2023 the Committee reported on the 31 global systemically important banks it had been tracking, nearly ten years after publication and seven years after the expected compliance date, and found that additional work was required at all of them.
All of them.
Those banks were never short of software, or of money to buy more. The Committee’s recommendation was about people. It asked banks to foster “a culture of ownership and accountability for data quality across the organisation,” which is a polite way of saying the records had no owners.
Nobody will examine a $2 billion direct lender against BCBS 239. The lesson travels anyway. If the tool were the bottleneck, the biggest banks would have finished years ago.
Things People Buy Instead
Each of these is useful. None of them, installed, gives you the record.
- A data warehouse. Your three disagreeing numbers get one address and keep disagreeing, faster, somewhere with better uptime.
- Portfolio monitoring software, which is usually the tool you already bought. Ask who maintains the borrower list inside it. If the answer is a person’s name, you have your answer.
- A master data management platform. Matching engines are good now and affordable at mid-market scale, and on the first day of the project the implementation team will ask you which record wins whenever two of your sources disagree about the same borrower. That question was always yours to answer.
- The dashboard, which comes last and inherits every disagreement beneath it.
Same pattern each time. A purchase stands in for a decision, and the decision stays unmade.
What It Looked Like When It Worked
The cleanest version I’ve built was at a specialty finance investor where I ran data science, across 11 data domains and hundreds of thousands of individuals and policies. One person could appear under a maiden name in one feed, with a transposed birth date in another, and against a policy number reissued after a conversion in a third. We settled the grain first, one person and one policy, with a written rule for which source won each field. Then the matching. Then the checks.
Data preparation time fell 84%, from weeks to days.
Infrastructure costs fell 35%, and that second number surprised the finance team more than the first, because it came from switching things off. Once one record existed, a good share of the extracts feeding the old reports had no reason to run, and nobody missed them.
Neither number came from a model. The modeling came later and got easier, because it was reading a record instead of arbitrating one. The layered architecture underneath, raw to cleaned to trusted across those eleven domains, is a longer story for another piece.
Credit and insurance land in the same place with different nouns. The fund version starts at the borrower, and KORE1’s private credit data operations consulting begins there. The carrier version starts at the policy, and life and annuity data operations lays out one policy as five files remember it.
Five Checks You Can Run on One Borrower
- Ask three systems for the exposure to one borrower and write the answers down before anyone reconciles them.
- Find the written sentence that says which answer is right. A slide counts. An email from 2022 counts. Memory doesn’t.
- Pick any field on that borrower, the maturity date for instance, and ask where its authority lives. Is it the credit agreement, the latest amendment, or the loan system? If three people give three answers, you’ve found your first rule.
- Look for a single field anywhere marked as not trusted.
- Time how long it takes to answer the lender’s question from scratch.
Score it plainly. Five clean answers means you have a foundation and should go and work on something else. Three or fewer means every AI project on your roadmap will spend its first quarter doing this work under a different name, which is how most of the stalled projects I get called into ended up where they are. I wrote about that pattern in why document extraction projects stall.
Check four deserves a sentence of its own. If nothing in your records is tagged uncertain, the uncertainty hasn’t gone anywhere. It’s in someone’s head, and it leaves when they do.
Who Owns the Record Once It Exists
An unowned record decays faster than anyone budgets for.
Two seats hold it. A data governance analyst owns the definitions, the authority table, and the library of checks, and signs off whenever a new source arrives or an old one quietly changes meaning. A data warehouse engineer owns the pipelines that build the record and run the checks every night. Neither role is exotic. Both are hard to fill well, because the strong candidates can also read a credit agreement, and that pool is small.
KORE1 places both, through data governance analyst staffing and data warehouse engineer staffing, often on contract terms while the record is being built, and it reports 92% retention on placements at the twelve-month mark. If you’re deciding which seat to fill first, the split looks a lot like the one in data engineer versus data architect.
Questions I Get About the Record
Is a Data Warehouse a Single Source of Truth?
Only if the records inside it already agree. A warehouse gives three disagreeing numbers one address, and the disagreement survives the move intact.
Build the canonical record and its checks first, then load the warehouse from that record, because the order is cheap to get right on day one and very expensive to reverse once reports depend on it.
Golden Record, Master Data, Single Source of Truth. Same Thing?
Close cousins with different scope. A golden record is one resolved entity, master data management is the discipline that maintains those records, and a single source of truth is the promise that a question gets the same answer twice.
In a credit fund I care less about the label than about whether the tags exist. Vendors use all three words for the same product, which doesn’t help.
What Does One Look Like at a Direct Lending Fund?
One exposure number per borrower, the same every time anyone asks. Underneath it sit a borrower key at the ownership-group grain, a funded-share field with the administrator named as its authority, and a check that ties it to the loan system within a tolerance.
Plus a tag on the delayed-draw tranche that says undrawn, excluded, and why.
Do We Need Master Data Management Software First?
Not first. Write the grain sentence and your first twenty rules before you evaluate any platform, because every vendor will ask you for them in week one.
Already own one? Keep it. Most of what fails sits upstream of the software, in decisions about grain and authority that somebody made years ago in a meeting and never wrote down anywhere.
Realistically, How Long Does This Take to Build?
Four to six weeks for one entity type, with the person who does the work in the room part time and one engineer full time.
Borrowers go first, because exposure questions land on them. Facilities and positions come next. A whole book takes longer, and nearly all of the extra time goes into ownership groups, where you’ll find entities your own team didn’t know were related, including at least one that was flagged in a credit memo years ago and then forgotten.
Who Should Own It, Operations or Technology?
Operations owns the definitions and technology owns the plumbing. When technology owns both, the record ends up describing the systems instead of the business.
The governance analyst belongs on the operations side of that line even when the reporting line runs into IT. If you’re hiring for that seat, our guide on how to hire a data governance analyst covers the screen.
Pull One Borrower Before Friday
Pick the borrower you’d least like a lender to ask about, then ask your loan system, your administrator, and your newest workbook for its exposure, and put the three answers on one page with today’s date. Then write the sentence that says which one is right.
If that sentence takes more than an hour, you’ve found where your foundation starts. Read the record before you buy anything to sit on top of it.
I compare notes on this with operators most weeks and I’m easy to find. Connect with me on LinkedIn. If the gap turns out to be a seat rather than a sentence, talk to KORE1 about the hire.
