How should fintech teams use data during merchant onboarding to reduce fraud risk?

Using onboarding data as a fraud filter, not an admin step

Merchant onboarding works best when each data point is treated as evidence about the applicant’s risk profile. Identity documents, business registration details, bank account ownership, device signals, website content, and expected transaction patterns can all reinforce or contradict each other. The practical question is not whether the data is complete, but whether it tells a coherent story that supports the merchant’s stated activity. For a useful overview of control-driven screening and lifecycle thinking, see NIST Cybersecurity Framework 2.0.

Teams often underuse onboarding data by checking only whether fields are filled in, rather than whether the combined profile makes sense for the business model and expected payment behaviour. That weakens fraud detection because synthetic, misrepresented, or mule-linked merchants usually stand out through inconsistencies across sources, not through any single obvious defect. In practice, many security teams discover onboarding gaps only after disputed transactions, account takeovers, or laundering patterns have already moved through the platform.

How onboarding evidence should be combined and weighted

Effective merchant screening usually works as a layered comparison exercise. First, verify the merchant’s declared identity and legal existence. Then compare that declaration against payment rails, beneficial ownership, domain age, device reputation, geolocation, and early transaction expectations. No single signal should decide approval on its own unless the organisation has a clearly defined rule for that signal. Instead, data should be used to test consistency across the application, the business, and the technical footprint.

That approach matters because fraud often appears as a pattern of small mismatches. A newly formed entity may claim a low-risk retail profile while showing unusual refund behaviour, proxy use, or high-risk card-not-present characteristics. A legitimate merchant may also look unusual at first, which is why review criteria must distinguish between explainable exceptions and combinations that indicate concealment or laundering. The strongest programmes define which signals are hard stops, which require manual review, and which only change score weighting.

• Identity and business evidence should support each other, not sit in separate silos.
• Technical signals should be interpreted in context, especially for high-growth or cross-border merchants.
• Expected volume, refund rates, and product type should be compared with the onboarding story before approval.
• Outlier handling should be explicit, so analysts know when a mismatch is a normal exception versus a fraud indicator.

Where teams get this wrong is assuming that better data automatically means better decisions. Data only reduces fraud when it is tied to a decision model that can escalate uncertainty, delay approval, or trigger enhanced due diligence. Without that, teams may collect more information while still missing the underlying risk.

When legitimate merchants look risky and risky merchants look polished

Tighter onboarding controls often increase friction and manual review, so teams have to balance fraud prevention against conversion and merchant experience. That tradeoff becomes sharper for marketplaces, embedded finance, and cross-border acquisition, where normal business diversity can resemble fraud if the scoring model is too rigid.

One genuine edge case is the fast-growing merchant with sparse historical data. That is not the same as a shell company, but it still needs compensating controls because the absence of history limits confidence. Another common exception is the business that operates through third-party platforms or distributed sales channels, which can distort device and transaction patterns without indicating abuse.

There is also a practical consensus gap around how much weight to place on behavioural and device intelligence during onboarding. Most practitioners agree it is useful, but not all agree on when it should override formal business verification. The safest position is to treat such data as a strong corroborating layer, not as a substitute for legal and financial due diligence.

Risk and Threat Considerations

Merchant onboarding data is exposed to manipulation, concealment, and selection bias. If teams rely on static document checks or overly permissive scoring, fraudulent merchants can present a coherent-looking application while hiding the signals that matter most for chargeback abuse, laundering, or card testing.

Failure mechanism: The risk materialises when onboarding controls fail to correlate identity, ownership, device, website, and payment behaviour into one review path. Adversaries exploit that gap by supplying plausible documents, reusing clean infrastructure, or fragmenting their activity so no single signal appears severe enough to block approval.

Impact: The platform may onboard merchants that generate losses, drive dispute volume, or create regulatory exposure. Weak onboarding also pollutes risk models downstream, because approved fraudulent merchants can distort thresholds, create false confidence, and increase the cost of later remediation.

Practitioner Guidance

What to prioritise: Prioritise cross-signal consistency over data volume. A smaller set of well-correlated signals is more useful than a long checklist of fields that are never compared against one another.

Decision rule: If the merchant story is internally consistent but technically unusual, route it to review rather than auto-decline. If the story conflicts across legal, financial, and behavioural evidence, treat that as a stronger fraud indicator than any single red flag.

What to verify: Verify that analysts can explain why a merchant was approved, declined, or escalated from the evidence on record. If the decision cannot be reconstructed from the data, the onboarding process is too opaque to trust.

Practitioner takeaway: Merchant onboarding data is most valuable when it supports a defensible risk judgment, not when it simply records more applicant information.

Related resources from NHI Mgmt Group

• How should security teams use sensitive data discovery to reduce AI risk?
• How can teams reduce risk when agents use webcam or device-like inputs during testing?
• How should security teams use data classification to reduce access risk?
• How do security teams reduce the fraud risk after payroll data leaks?