When your KYB tool, fraud tool, and processor each tell a different story about the same sub-merchant
Vendor disagreement about a sub-merchant is not a data-quality problem you can clean your way out of. It is structural. Here is why it happens, why the usual workarounds break at portfolio scale, and how to decide on one reconciled record instead of three partial ones.
What do you do when your KYB tool, fraud tool, and processor disagree about a sub-merchant?
You land every signal on one record per sub-merchant, adjudicate the disagreement with your codified policy, and record the adjudication as a decision. The call gets made on the whole picture instead of one vendor's slice, and the reasoning survives a later audit.
That is the short answer. The rest of this page is why the disagreement happens in the first place, why the common workarounds stop working somewhere around a few hundred sub-merchants, and what deciding on a reconciled record actually looks like day to day.
The disagreement is structural, not a bug
Here is a case every underwriting lead at a payment company has seen some version of. The KYB vendor returns a clean verification: the legal entity exists, it is in good standing, the beneficial owners check out. The fraud tool has the same business at an elevated score: velocity is up, the device pattern looks off, something about the payment stream it does not like. The processor's reporting shows eighteen months of settlement with no disputes to speak of. Three vendors, one sub-merchant, three verdicts.
The instinct is to treat this as a data-quality problem. One of the vendors must be wrong; find out which and fix the feed. That instinct is mistaken, and acting on it wastes months. The vendors disagree because they are measuring different things:
- The KYB vendor sees the legal entity. Registry filings, formation documents, beneficial owners, standing. Its verdict is about whether the business on paper is real and well-formed. It knows almost nothing about what the business does with a card terminal.
- The fraud tool sees transaction behavior. Devices, velocities, payment patterns, network effects across its own customer base. Its score is about the stream, not the company. It may not know or care what the legal entity is.
- The processor sees settlement history. Volume, disputes, refunds, reserves, keyed to a MID. Its view is backward-looking and financial. A business can be drifting into trouble for months before it shows up here.
Each vendor is right about its slice. None of them has the whole business. And the disagreement goes one level deeper than the verdicts, because the vendors do not even agree on who the merchant is. The KYB vendor keys on the legal name. The application came in under a DBA. The processor knows a MID, and possibly a second MID the same business opened last year for a second location. The fraud tool keys on whatever identifier was passed at integration time. "Same sub-merchant" is a conclusion someone has to reach, not a field someone can join on.
So the honest statement of the problem is this: every multi-vendor risk stack produces multiple partial, differently keyed, sometimes contradictory stories about every sub-merchant in the portfolio, all the time, by design. The question is not how to make the vendors agree. They will not. The question is where the stories become one story, and who decides when they conflict.
What teams do today, and where each approach breaks
Three coping strategies cover almost every team we talk to.
The swivel chair. An analyst opens the KYB console, the fraud console, and the processor portal, reads all three, and forms a judgment. This works, in the sense that a good analyst reaches a good decision. It fails on everything else. The judgment lives in the analyst's head; what gets written down is the verdict, not the reconciliation that produced it. Two analysts weigh the same conflict differently on different days. And the throughput ceiling is the number of analysts you employ, which is exactly the constraint a payment company boarding at volume cannot accept.
First vendor wins. The stack is wired so that whichever tool fires first, or whichever one sits at the top of the waterfall, determines the outcome. Clean KYB means approve; the elevated fraud score is a note in a queue nobody rereads. This is fast and consistent, and it is consistent in the wrong way: it systematically decides on one slice of the picture. The sub-merchant your fraud tool was right about boards anyway, and the first anyone hears of it again is a dispute spike, or a network flag with a clock attached.
The reconciliation spreadsheet. Somebody exports from each console and merges by hand, weekly or monthly, name matching DBAs to legal names to MIDs across tabs. This at least takes reconciliation seriously. But it is point-in-time work that is stale before it circulates, the identity matching is redone by hand every cycle, and the spreadsheet records none of its own reasoning. When someone asks six months later why row 214 was approved, the answer is an archaeology project through versions of a file.
All three approaches share a failure mode: the reconciliation happens somewhere unrecorded, in a head, in a wiring diagram, in a file, and so the decision cannot later show what it saw. At ten sub-merchants a month, this is survivable. At hundreds, with a portfolio compounding underneath, it is not.
The automation ceiling: you cannot auto-approve on a stack that cannot agree who the merchant is
Fast onboarding is the whole commercial point of running your own underwriting. The promise to your platform customers is minutes, not the three days the acquirer used to take. That promise depends on automating the clear cases, and here the disagreement problem stops being an operations annoyance and becomes a revenue constraint.
An auto-approval is a claim: every signal we checked came back inside policy. You can only make that claim if the signals were actually brought together, on the same business, before the decision fired. A stack that cannot resolve whether the KYB result and the fraud score describe the same sub-merchant cannot make the claim. Teams in that position quietly route everything ambiguous to manual review, and since identity ambiguity is common, the manual queue swells until the minutes-not-days promise is fiction.
Notice what forces the manual review. It is usually not that any single vendor said no. It is that the record disagrees with itself and nothing in the stack is authorized to resolve the disagreement. Recorded disagreement without an adjudication rule is an automatic escalation, every time. Which means the ceiling on your automation rate is not set by your vendors' accuracy. It is set by whether you have codified what happens when they conflict.
How it works on one record
FinQub's decision engine decides on the reconciled record. It sits alongside the KYB, sanctions, fraud, and monitoring vendors you already run; the deciding is the product, and one continuous record per sub-merchant is the consequence. Concretely, for the disagreement problem:
Signals land on the sub-merchant, not in consoles. Every vendor output, the KYB verification, the fraud score, the sanctions result, the processor's settlement and dispute data, attaches to one record per sub-merchant, tagged with which vendor produced it, when, and under which version of your policy it was evaluated. The DBA, the legal name, and the MIDs resolve to that same record, so "same business" is established once, not re-derived per spreadsheet cycle.
Disagreement is adjudicated by explicit policy. Your rules say what happens when the slices conflict: a clean KYB with an elevated fraud score in this merchant category routes to review; settlement history of this depth offsets a velocity signal of that size; a sanctions hit trumps everything regardless of what the other tools say. These are your risk-appetite calls, written down as rules the engine executes the same way every time. Vendor outputs are signals. The policy decides.
The adjudication is itself a recorded decision. When the engine resolves a conflict, the resolution is captured like any other decision: the conflicting signals, the rule that applied, the policy version, the outcome. When the policy routes to a human instead, the analyst decides on the assembled record, in one place, and the override, who made it, when, and the rationale, is captured alongside the policy's verdict. The reconciliation stops being invisible work. It becomes part of the record.
Later, the story reads as one story. When the acquirer, the sponsor bank, or an examiner asks about a specific sub-merchant, the answer is one continuous account: boarded on these signals under this policy, monitored since, this conflict arose, adjudicated this way, by this rule or this person, for this stated reason. Not three console exports and a reconstruction. And because the record is continuous, you can replay any decision as it stood at decision time, with the signals and the policy version that were actually in force, not the ones in force today.
One consequence worth making explicit: the automation ceiling moves. With adjudication rules in place, recorded disagreement is no longer an automatic escalation. The conflicts your policy can resolve, it resolves, recorded; the ones it cannot, it routes to a human with the full picture already assembled. Manual review becomes the deliberate exception your policy chose, not the default your architecture forced.
The ISO-to-PayFac angle: you inherit this problem on day one
If you are running an ISO book today and moving toward registration, this problem is easy to underestimate, because as an ISO you have never had it. The acquirer underwrites. The acquirer's stack disagrees with itself, and the acquirer's analysts reconcile it. You see the output: a merchant approved or declined.
The day you become the PayFac, the decision moves to you, and the reconciliation problem moves with it. You will assemble a vendor stack, KYB, sanctions, fraud, monitoring, on top of your processor relationship, because no single vendor covers the ground; that is the shape of the stack you inherit when you move up. Which means that from your first boarded sub-merchant, you own a multi-vendor disagreement problem you have zero institutional practice resolving. The acquirer had years of accumulated adjudication habits, staff, and precedent. You start with an empty rulebook and a live portfolio.
Two things make this sharper than it looks in the registration planning deck. First, the decisions compound. Boarding is one decision, but monitoring after boarding generates conflicting signals for the life of every sub-merchant, so the reconciliation load scales with portfolio size, not with boarding volume. Second, the clocks are shorter than your spreadsheet cycle: network monitoring programs now put dated deadlines on flagged sub-merchants, and a reconciliation process that takes a week does not fit inside them. Slow reconciliation used to cost accuracy. Now it also costs money and, in the worst case, the sub-merchant relationship, because an unresolved disagreement on a MATCH-relevant termination decision is exactly the call you least want to make on one vendor's slice of the story.
The teams that handle the transition well treat adjudication as part of the underwriting policy they write before registration, not as an ops problem they discover after. Decide, in rules, what wins when the slices conflict. Put the rules somewhere they execute consistently. Record every resolution. That is the institutional practice the acquirer had and you do not, and it can be codified instead of accumulated.
Frequently asked questions
What is cross-vendor signal reconciliation for sub-merchants?
Cross-vendor signal reconciliation is the practice of landing every vendor's output about a sub-merchant on one record, resolving that they all refer to the same business despite different identifiers, and adjudicating disagreements between them with explicit policy rules rather than analyst improvisation. The KYB result, the fraud score, the sanctions hit, and the processor's settlement view attach to the same sub-merchant, tagged by source and time, and the decision is made on the reconciled picture. The adjudication itself is recorded, so the decision can be explained later.
Why do my vendors disagree about the same sub-merchant?
Because each one measures something different. The KYB vendor verifies the legal entity against registry data. The fraud tool scores transaction behavior on a device and payment stream. The processor reports settlement and dispute history against a MID. These are three different lenses on three different slices of the business, keyed to three different identifiers. Disagreement between them is the expected output of the architecture, not a malfunction, and a sub-merchant that looks clean through one lens and risky through another is exactly the case that needs a deliberate decision.
Is this the same as merchant onboarding orchestration?
No. Orchestration sequences vendor calls: run KYB first, then sanctions, then the fraud check, branch on the results. It answers the question of which vendor to call next. Reconciliation and adjudication are the decision layer and the record beneath whatever sequence you run: once the signals exist, something has to resolve that they describe the same business, apply policy when they conflict, and record how the conflict was decided. You can orchestrate perfectly and still have three unreconciled stories about one sub-merchant.
Does FinQub replace my KYB vendor, fraud tool, or processor?
No. FinQub sits alongside the vendors you already run and decides on what they produce. Each vendor keeps doing what it is good at. Their outputs land as signals on one record per sub-merchant, FinQub's decision engine applies your codified policy to the full set, and the decision, the signals it saw, and any analyst override are captured together. If you swap a KYB vendor next year, the record and the policy survive the swap.
What happens when an analyst overrides the policy on a disagreement?
The override becomes part of the decision record. The policy's verdict, the analyst's decision, who made it, when, and the stated rationale are captured on the same sub-merchant record as the conflicting signals that triggered the review. That matters twice: it is what a sponsor bank or acquirer reads when they ask how a call was made, and it is the raw material for tightening the policy, because a pattern of overrides on the same rule is the signal that the rule is wrong.
Cross-vendor disagreement is one face of a broader fact about multi-vendor risk stacks: the tools do not talk, and the decision has to be made anyway. The stack you assemble on the way from ISO to PayFac produces the signals; continuous monitoring keeps producing them after boarding; and point-in-time replay is what the one continuous record makes possible when someone asks how a call was made. If you want to see how the adjudication works on your stack and your policy, book a short walkthrough below.