Last updated: October 1, 2026
Entity resolution is the work of deciding which records in different systems describe the same real-world borrower, person, or company, and which only look alike. On a loan book it has two halves. You match the names that mean one entity, then you relate the entities that make up one credit.
Sixty-two borrowers. The fund’s systems held 291 names for them.
I got that count the dull way. Export the borrower column from every system that has one, stack the exports in a single sheet, drop the exact repeats, and count what’s left. It wasn’t on anyone’s list. I wanted the size of the problem written down before a vendor arrived with the cure.
Below is one of those borrowers, as five systems knew it. I’ve changed the name and kept the shape.
| System | What it calls the borrower | What it keys on |
|---|---|---|
| Loan system | Merrow Valley Foods Holdings, LLC | Facility number |
| Administrator’s position report | MERROW VLY FOODS TL-B | Investment code |
| CRM | Project Larder (Merrow Valley) | Deal ID |
| KYC file | Merrow Valley Foods, Inc. | Tax ID |
| Bank wire detail | MVF OPERATING CO | Originating account |
Read down the middle column and it looks like five spellings. Three of them are. The other two are a different company.
The LLC is the borrower under the credit agreement. The Inc. is its operating subsidiary. It guarantees the term loan, it was the entity somebody ran KYC on when the deal was still a term sheet, and it’s where the wires come from, because that’s where the cash sits. A later equipment line had been booked under the subsidiary’s name, since that was the name on the wire instructions. So the concentration report carried Merrow Valley twice, at 3.1% of the book under one name and 1.4% under the other. The single-obligor limit in the fund’s own credit facility was 4%, measured on an obligor together with its affiliates.
Neither line looked wrong. Nobody had added them.
This is the part of a data foundation that’s still done by hand almost everywhere I go. Usually by one person. From memory. I wrote about that person in one person is the database. Here I want to describe the work itself, because it has a name and a method, and both are older than the tool you already bought.
You’re reading this on KORE1’s site. KORE1 is a recruiting firm, and its data engineering and data science recruiting group places the two kinds of people I describe near the end. The count above needs neither of them. It needs five exports and about an hour.
What Entity Resolution Means on a Loan Book
Entity resolution is the process of deciding whether two or more records refer to the same real-world thing, and recording that decision so every system can use it. Statisticians call it record linkage. In lending, the thing is usually a legal entity, and the records disagree about its name, its identifiers, or which entity is meant.
Most definitions stop at matching. Credit can’t. A credit committee, or the bank that lends to the fund, asks about exposure, and exposure follows the credit, which is often several legal entities bound together by one agreement. So there are two jobs. I keep them apart.
The first is matching. MERROW VLY FOODS and Merrow Valley Foods Holdings, LLC are one company written two ways. Decide it once, record it, move on.
The second is relating. The holding company and the operating subsidiary are two companies, and merging them would be a mistake I’ve watched a clean-up project make. They share one borrower group. Somebody has to say so, and say what role each one plays. Borrower. Guarantor. Sponsor. Payor.
Software is good at the first job. The second is written in the credit agreement, in the definitions of Borrower, Loan Parties, and Guarantors, and no amount of string comparison will find it there. What the record should contain once the names are attached, and at what grain it should be kept, I covered in what a single source of truth means at a credit fund. This piece is about the attaching.
Three Keys Before One Name
Large banks file a quarterly loan-level report with the Federal Reserve called the FR Y-14Q. On its corporate loan schedule, every row opens with three identifier fields before it reaches the obligor’s name. The Fed’s instructions for the FR Y-14Q define them like this.
| Field | The Fed’s wording | What it answers |
|---|---|---|
| 1. Customer ID | “a relationship concept under which multiple borrowers are aggregated because they have related risks” | Which group is this? |
| 2. Internal ID | “a borrower concept that identifies the entity under which multiple loans are aggregated” | Which legal entity? |
| 3. Original Internal ID | “the internal identification code assigned to the obligor in the previous submission” | What was it called last quarter? |
| 4. Obligor Name | “Full legal corporate name is desirable.” | What do people call it? |
Group, entity, and the entity’s previous ID, so that a renumbered obligor can still be followed from one quarter to the next. The name comes fourth. The instruction for it is the word desirable.
A private credit fund doesn’t file this report and I’m not suggesting it should behave as if it did. But whoever designed that schedule had the five-systems problem at the scale of every large bank in the country, and what they wrote down was a structure in which the name is the last thing anyone relies on. I’d copy the structure.
The problem also runs the other way. Your fund is a borrower in somebody else’s systems. In a March 2026 brief on counterparty exposures to private credit, two researchers at the Office of Financial Research tried to total bank lending to business development companies from that same Y-14 data. They reported that it was hard to capture in full, because many BDCs borrow through special purpose vehicles, a single BDC may have several, each can be dedicated to one bank lender, and the obligor names vary. Their method left the SPV borrowings out. The people holding the regulatory data had a names problem too.
The Law Already Picked the Name
Every secured lender has resolved each borrower at least once. At closing. They had to.
Under UCC 9-503, a financing statement names a registered organization sufficiently only if it gives the name stated on the public organic record most recently filed with its jurisdiction of organization. A trade name by itself doesn’t count. Section 9-506 adds that a filing with the wrong name is seriously misleading, unless a search under the correct name, run through the filing office’s standard search logic, would still turn it up.
That’s an odd thing to find in a statute. It defines the canonical name of a company, says which document the name comes from, and attaches a consequence to getting it wrong. Your counsel followed it to the letter, because lien priority rode on it. Then the closing binder went on a shelf, and the loan system got whatever the deal team had been calling the company since the first call.
So I start there. Pull the charter or the certificate of formation from the closing set. The name on it, the state, and the state’s file number go into the record as the anchor. Tax ID next. A Legal Entity Identifier, or LEI, if the borrower has one, which in the middle market is far from a given. Everything else anybody has ever typed becomes an alias that points at the anchor.
Read the record. It’s in the binder.
How the Matching Runs
The largest matching job I’ve run was on people rather than companies. At a specialty finance investor where I led data science, we matched hundreds of thousands of individuals and policies arriving from carriers, servicers, and medical record providers, none of which agreed on how to write a person down. The method is the one I’d use on a single fund’s loan book. Volume was the difference.
The best public description of that method is a Census Bureau working paper on its Person Identification Validation System, which assigns one protected key to each person across federal, commercial, and survey files. Read it for the order of operations.
- Clean before you compare. Strip the punctuation, the capitals, and the LLC, and keep the original string beside the cleaned one. The Census authors warn that working out these edits “can take days or even weeks.” They’re right.
- Exact identifiers go first. In the paper’s results, checking a Social Security number settled 76% of the records that carried one in two large commercial files, before any scoring started. For borrowers the equivalents are the tax ID and the state file number.
- Then block. Comparing every record with every other grows with the square of the list, so you compare only records that already share something sturdy, such as a state of organization or a ZIP code. The first pass is strict. Later passes loosen, and the paper is plain that looser passes “may produce weaker links.”
- Two cutoffs, three piles. Above the upper score a pair is a link. Below the lower, it isn’t. The pairs in between go to a person.
- Who reviews the middle pile? For borrowers it should be someone who can open the credit agreement, since half the questions turn out to be about which entity signed.
That middle pile is small and it is nearly all of the work. On the person-matching build, most records never needed a score at all, and the days went to the pairs where a name, a birth date, and an address each half agreed with the record on the other side and nothing settled it outright. No model shortened that. A written rule for each kind of disagreement did.
If the threshold question sounds abstract, you already run one. Sanctions screening is entity resolution with a penalty attached. OFAC’s Sanctions List Search scores names with two algorithms, Jaro-Winkler for spelling and Soundex for sound. Asked whether it recommends a particular score for deciding a match, OFAC’s published answer is that it “cannot make such a recommendation,” and that users “must make their own match threshold determinations.” The agency that wrote the list won’t pick your cutoff. I wouldn’t let a vendor pick it either.
What the Crosswalk Looks Like
The output of all this is one table. I call it the crosswalk. Every name any system has ever used gets a row, and each row points at an entity and says how it got there. Here are the same five names, resolved.
| Name as found | Source | Entity | Group | Role | How it matched |
|---|---|---|---|---|---|
| Merrow Valley Foods Holdings, LLC | Loan system | E-0417 | G-0112 | Borrower | Organic record, exact |
| MERROW VLY FOODS TL-B | Administrator | E-0417 | G-0112 | Borrower | Scored, then reviewed |
| Project Larder (Merrow Valley) | CRM | None | G-0112 | Deal name | Assigned by hand |
| Merrow Valley Foods, Inc. | KYC file | E-0418 | G-0112 | Guarantor | Tax ID, exact |
| MVF OPERATING CO | Wire detail | E-0418 | G-0112 | Guarantor, as payor | Scored, then reviewed |
Two entities, one group, five names. The concentration test runs on the group column now, and 4.5% shows up as 4.5%.
Three rules keep it honest. Nothing is ever deleted, so an alias that was wrong stays in the table marked as wrong, with the date and the person who caught it, because the next system migration will produce the same wrong name again and someone will need to know it was already ruled on. Merges can be undone. And some pairs carry a never-merge flag. Two entities with different tax IDs are two entities, however alike the names look.
Names change after closing, too. An add-on acquisition brings in a new co-borrower. A rebrand changes the charter. The UCC treats that as an event with a clock on it, since 9-507 gives a secured party four months to amend a filing once a name change has made it seriously misleading. So somebody at the fund or its counsel is already watching for it. Send that notice to the crosswalk as well. The entity ID stays. The old name stays. The new one goes in with a date.
None of this is special to borrowers. The same table pointed at a borrower’s customers, account debtor by account debtor, is what fixes the debtor-name problem I described in the fields a machine misreads on a borrowing base certificate. Pointed at an ERP’s customer and vendor lists, it’s the subject of Colin Boothe’s guide to cleaning duplicate records with AI. And in a layered build it’s the first thing in the middle layer, which is why the dashboard comes last.
Who Keeps It True
On a book this size the whole job is about a week for two people, and then an hour or so a month. No purchase order involved. If names are only one of several things in this state, a timed look at the whole data foundation is the wider version of the same count.
One of them owns the rules and the middle pile. That’s a data governance analyst, or at a smaller fund the operations person who already knows every borrower by its three names. One qualification matters more than the rest. Can they read the definitions section of a credit agreement and come back with the list of loan parties?
The other, usually a data warehouse engineer, builds the plumbing so that no system can create a borrower by itself. New names land in a queue, get matched or sent to review, and only then appear anywhere else, whether the tables live in Snowflake, Databricks, or an ordinary PostgreSQL database. Whether that’s an engineer’s job or an architect’s depends on how many systems you’re wiring together, and KORE1’s comparison of data engineer and data architect roles is a fair guide to which one you’re short. Either seat can start as a contract engagement while the backlog of old names is cleared. KORE1 puts its twelve-month retention on placed hires at 92%. That matters here, because a crosswalk decays quickly once whoever understood it has gone.
The cheapest moment to resolve an entity is the closing itself. Assign the ID from the organic record before the first system hears the name. Few funds I’ve worked with do it. Most wish they had.
What Comes Up Once You Count the Names
Entity Resolution vs. Deduplication. Is There a Real Difference?
Deduplication removes repeated records inside one list, while entity resolution decides which records across several lists describe the same thing and keeps all of them, linked.
A deduplicated borrower list has thrown away the evidence of how each system spells the name. You’ll want that evidence the next time a file arrives. Keep the aliases.
Will a Tax ID or an LEI Settle It Without Any Matching?
Partly, because an identifier tells you which legal entity a record means and nothing about which entities share one credit agreement.
A holding company and its operating subsidiary each have their own tax ID, so the identifiers confirm they’re different and stop there. Coverage is thin as well. The Fed’s own loan schedule lets a bank report NA where an obligor has no taxpayer identification number, and administrator reports and wire details rarely carry either number. Identifiers shrink the pile. The rest is reading.
How Many Names per Borrower Is Normal?
Four to five names per borrower is what I usually find at a fund that has never counted.
The ratio matters less than the mix. If most of the extra names are spellings, you have a tidy-up. If many of them are separate legal entities, your exposure reports are probably splitting credits, and that’s worth an afternoon this month.
Can a Language Model Do the Matching?
A language model can propose matches well, and a person should still approve every match that isn’t backed by an identifier.
Models are good at seeing that MVF OPERATING CO probably belongs with Merrow Valley Foods. They’re also willing to say two unrelated companies with similar names are one, in the same confident tone. Use the model as a faster way to fill the middle pile. Give it the organic-record names to match against and make it state its reason. Which entities form the credit still comes out of the agreement, and I’ve written separately about testing a model on a credit agreement.
Our Book Is 40 Names. Does This Need Software?
No, at 40 borrowers a spreadsheet and the closing binders will do it in about two days.
Matching engines earn their cost when lists run to the tens of thousands or new names arrive daily, as account debtors do on receivables agings. A direct lending book of 40 doesn’t qualify. What it needs is the crosswalk, an owner, and a rule that new borrowers get an ID at closing.
What Happens When a Borrower Is Acquired or Renamed?
The entity keeps its ID and the new name is added as another alias with an effective date.
An acquisition can also move the entity into a different group. That’s a change to the relationship, and the entity row stays as it was. Record both dates. Reports for prior quarters should still come out the way they were filed, and they will if nothing in the crosswalk was overwritten.
Count Yours This Week
Export the borrower name column from every system that has one. Stack them, drop the exact repeats, and count. Divide by the number of borrowers you think you have.
Then take your ten largest exposures and write the organic-record name beside each alias. If any of the ten turns out to be two legal entities, rerun the concentration report by group and see whether anything moves.
If some names won’t sort, connect with me on LinkedIn and tell me what they look like. And when the crosswalk needs an owner you don’t have yet, ask KORE1’s recruiters about the role.
