A borrower pays on time at your Marikina branch for six months. Then she stops paying everywhere at once, and you find out she also had a loan at your Pasig branch, opened under “Maria Cristina De La Cruz” instead of “Ma. Cristina Dela Cruz.” Neither officer did anything wrong on their own file. What was missing was a duplicate borrower check across the whole book before the second release.
The short answer: before any new loan or renewal is approved, search every branch for the same person using normalized name plus birthdate, government ID number, and mobile number, not raw name text. Treat an ID match as a hard stop, a name-plus-birthdate or shared-mobile match as a hold that a manager clears, and anything weaker as a note. When a real match exists, approve against the borrower’s combined outstanding exposure, not just the one file in front of you.
This guide is for branch managers and credit leads at lending companies, small MFIs, and cooperatives with two or more branches or officers who keep their own lists. You get the matching rules, a normalization checklist for Filipino names with a worked example, a step-by-step desk routine, the combined-exposure math, what the other branch should and shouldn’t see under the Data Privacy Act, the traps that make the check useless, and a pre-release checklist.
Who this is for (and who can skip)
Use this if borrowers can walk into more than one of your branches, if officers keep borrower lists in separate spreadsheets, or if you have ever discovered a second active loan only after the first one went past due.
Skip it if you run a single desk where one person approves every loan from one borrower list. Even then, read the name normalization section; spelling variants create duplicates inside one list too.
Why raw name search misses the same person
Most desks “check for duplicates” by typing a name into a search box. That fails on Filipino names for predictable reasons:
- Abbreviations: “Ma.” and “Maria,” “Jose” and “Jose Ma.,” “Sto.” and “Santo.”
- Surname particles: “Dela Cruz,” “De la Cruz,” “Delacruz,” and “Dela-Cruz” are one family name typed four ways.
- Middle names vs. middle initials: one branch stores “Santos,” another stores “S.”
- Married names: a borrower may apply under her maiden surname at one branch and her married surname at another.
- Suffixes and nicknames: “Jr.” dropped on one form, “Tess” written instead of “Teresita.”
The fix is not a smarter officer. It is a fixed set of normalization rules applied before every comparison, plus identifiers that do not depend on spelling at all.
Normalization checklist (apply before comparing)
- Convert to one case and remove periods, hyphens, and extra spaces.
- Join surname particles: “de la,” “dela,” “del,” “de los,” “san,” “sta” become one token (so “De La Cruz” and “Delacruz” both read “delacruz”).
- Expand common abbreviations: “ma” to “maria,” “sto” to “santo,” “sta” to “santa.”
- Drop suffixes (Jr., Sr., II, III) for matching, but keep them on the record.
- Compare on first name + surname + birthdate. Use middle name only as a tie-breaker, never as a reason to say “different person.”
- Store mobile numbers in one format (for example, 11 digits starting with 09) so “+63 917…” and “0917…” match.
- Store government ID as ID type plus number with no spaces or dashes.
Here is the opening case run through those rules. The two files looked like strangers in a raw name search. After normalization they produce the same match key.
| Field | Marikina file (as typed) | Pasig file (as typed) | After normalization |
|---|---|---|---|
| First name | Ma. Cristina | Maria Cristina | maria cristina (same) |
| Middle name | S. | Santos | tie-breaker only; initial agrees |
| Surname | Dela Cruz | De La Cruz | delacruz (same) |
| Birthdate | 03/14/1988 | 14 March 1988 | 1988-03-14 (same) |
| Mobile | +63 917 ••• 0142 | 0917-•••-0142 | 11 digits starting 09 (same) |
| Result | Strong match on name + birthdate, plus the same mobile: hold the Pasig release until a manager clears it | ||
The middle name, the field officers often use to say “different person,” is the only one that disagreed on paper. That is why it only breaks ties.
Matching rules: what each signal means
| Signal found in another branch’s file | Strength | Desk action |
|---|---|---|
| Same government ID type and number | Hard match | Block release. Manager confirms it is the same person and applies combined exposure. |
| Same normalized first name + surname + birthdate | Strong | Hold. Officer sights the original ID in person and asks about other loans with you. |
| Same mobile number on a different borrower name | Strong | Hold. Call the number; check if it is a shared household phone or one person using two names. |
| Same normalized surname + birthdate + same barangay | Medium | Officer reviews both files before approval; note the finding. |
| Same guarantor or co-maker on three or more active loans | Watch | Review the guarantor’s total exposure before accepting them again. |
| Name match only | Weak | Record it, no hold. Common names will match strangers. |
The guarantor row matters because a duplicate check that only looks at borrowers misses the person quietly co-signing for half a barangay. Our guide on keeping guarantor and co-maker files clean covers how to record them so they can be searched.
How to run a duplicate borrower check before every release
Run the same steps in the same order on every application, renewal, and top-up, and make each step leave something on the file the approver can see.
| Step | Who | What they do | What goes on the file |
|---|---|---|---|
| 1. Capture | Loan officer at intake | Enter name, birthdate, ID type and number, and mobile in the fixed formats above | Completed KYC fields and the ID scan |
| 2. Search | Credit lead or admin with a view of every branch | Search the ID number first, then the mobile, then the normalized surname | Note: date, who searched, terms used, hits found |
| 3. Classify | Same searcher | Grade each hit with the matching table | Note: hard, strong, medium, watch, or weak |
| 4. Confirm | Officer, face to face | On a hold, sight the original ID and ask the borrower directly about other loans with you | Note: the borrower’s answer, in their words |
| 5. Size | Credit lead | For a same-person match, add up installments across branches and test against your cap | Combined-exposure line in the credit memo |
| 6. Release gate | Approver or checker | Confirm steps 2 to 5 are on the file before cash moves | Approval record |
Step 4 matters most. A borrower who mentions the Marikina loan when asked is a different credit from one who denies it; the answer drives the decision framework below.
Worked example: combined exposure
Here is an illustrative case to show the arithmetic. Your policy (yours to set) says total weekly installments to you must not exceed 30% of the borrower’s verified weekly net income.
| Item | Branch A (existing) | Branch B (new application) | Combined |
|---|---|---|---|
| Outstanding principal | ₱8,000 | ₱10,000 requested | ₱18,000 |
| Weekly installment | ₱500 | ₱650 | ₱1,150 |
| Verified weekly net income | ₱3,500 (same household, same sari-sari store) | ₱3,500 | |
| Installment as share of income | 14.3% | 18.6% if viewed alone | 32.9% |
Branch B, looking only at its own file, sees 18.6% and approves. Viewed together, the borrower is at 32.9%, over the 30% cap. The right answer is not automatically “decline.” Branch B could offer a smaller loan: at ₱550 a week the combined figure is ₱1,050, exactly 30%. Or the desk can wait until the Branch A loan is closer to maturity.
Decision framework after a match
- Proceed as applied if the match is a different person (verified by ID in person) or the existing loan is fully paid and closed.
- Proceed with a reduced amount if it is the same person, the existing loan is current, and the combined installment fits your cap only at a smaller amount.
- Hold or decline if the existing loan is past due, if the borrower denied having another loan with you when asked, or if one person is using two names or IDs. Record the reason with a standard code, as in our post on loan decline reason codes.
What the other branch should see (Data Privacy Act)
A cross-branch check means one branch looks at another branch’s borrower. Under the Data Privacy Act of 2012 (RA 10173), personal information must be processed for a declared, legitimate purpose and must be “adequate and not excessive” for that purpose (Section 11). For a duplicate check, that translates into a short list.
| Share with the checking branch | Keep out of the check |
|---|---|
| That a match exists, and its strength | ID scans, payslips, and bank statements |
| Borrower number and home branch | Household, health, or family details from the interview |
| Loan status, outstanding balance, next due date | Collection notes and visit reports |
| Days past due, if any | The full government ID number in chats or shared sheets |
That last row carries extra weight. RA 10173 classes identifiers issued by government agencies, as well as age and marital status, as sensitive personal information (Section 3(l)). The fields that make matching reliable need the most care. Run the search inside your system, by people whose role allows it, never by pasting ID numbers into a group chat asking “kilala n’yo ba ito?”
Tell borrowers up front: your privacy notice and consent form should say you check applications against records at all your branches. Our borrower consent log guide shows how to record it, your Data Protection Officer confirms the lawful basis, and the National Privacy Commission publishes the Act and its guidance.
Traps that make the check useless
- Checking at first loan only. Run it again at every renewal and top-up. Duplicates often appear on the second or third cycle, when the borrower is trusted; build it into your renewal gating rules.
- Overrides with no reason. If a manager clears a hold, the system should record who cleared it and why. Pair this with maker-checker on release.
- Showing the whole file across branches. The other branch needs to know a match exists, the outstanding balance, and the payment status, not every document. Limit what is shown, as in the privacy table above.
- Merging records without a trail. When two records turn out to be one person, link them and log the merge; never delete one history.
- Relying on one person’s memory. “Ate Joy knows everyone” stops working the day Ate Joy goes on leave.
- Importing a borrower list without cleaning it. When a new branch moves its spreadsheet in, sort the file by ID number and mobile and resolve repeats in the sheet first. Duplicates imported on day one look like two real borrowers forever after.
- Searching after release. A check run after the cash is out only measures the loss. Make it a release gate.
Pre-release duplicate check checklist
If any line is blank, the loan waits.
- ID type and number entered with no spaces or dashes; mobile stored as 11 digits starting 09
- Whole-book search run on ID number, mobile, and normalized surname; date and searcher noted
- Every hit graded with the matching table
- Any hold cleared by a manager, with the reason written on the file
- For a same-person match: combined installment tested against your cap
- Guarantor’s other active co-signed loans counted
- Checker confirmed the note before approving release
Where PesoLend fits today
PesoLend keeps every branch’s borrowers in one organization, each with a borrower number, an assigned branch, and a loan officer. The Borrowers list searches by name, borrower number, phone, and national ID. Each borrower profile shows the home branch, KYC status, every loan on that file with its status, dated notes, and the ID or KYC scans in the borrower’s document vault.
Search follows staff roles and permissions. Admins and staff with no assigned branch see every branch; staff assigned to a branch see only that branch’s borrowers. That split suits this check: branch officers can’t browse other branches’ files, and the whole-book search sits with the credit lead or admin. Disbursement then goes through branch maker-checker approval, so the checker can confirm the duplicate-check note before cash moves.
To be plain about the limits: PesoLend does not flag possible duplicates automatically when a borrower is added or imported, does not normalize names, and does not merge borrower records. The duplicate borrower check is a desk step on top of search and notes. Search matches the characters you type, so one fixed format for ID and mobile numbers from day one is what makes it reliable; our KYC field checklist shows which fields to make required.
FAQ
Should a name-only match ever block a loan?
No. Common names will match strangers and frustrate good borrowers. Use name-only matches as a prompt to ask the borrower, not as a hold.
What if two family members share one mobile number?
That is common. Record the relationship on both files and look at household exposure, since both loans are often repaid from the same income.
Does a duplicate borrower check catch loans with other lenders?
No, it searches only your own book. For debts with banks and other lenders, the credit information system under Republic Act No. 9510, run by the Credit Information Corporation, collects basic credit data from credit providers. Ask the CIC how your type of entity submits and accesses it.
How often should we sweep the whole book for duplicates?
Check at every application and renewal, and run a full sweep monthly as part of your month-end close to catch records created before the rules were in place.
What to do next: pick one week of new applications, run them through the normalization checklist and the matching table above, and count how many matches your current name search would have missed. That number tells you whether to make the check mandatory before release.
Log in to PesoLend to search your borrower list across branches by ID number and mobile, and record each duplicate check as a note on the borrower’s file before the next release.