Merchant-risk case OS for payment facilitators that links email, phone, IP, and domain evidence before bad sellers go live.

1. AI-enabled fraud groups are increasing case volume and sophistication, which makes linear analyst hiring an increasingly losing response.
2. Fraud teams already own many raw signals, so the immediate software opening is workflow compression across those systems rather than one more detector.
3. Explainable linked evidence is becoming mandatory because investigators must justify onboarding decisions across phones, emails, IPs, domains, and prior attempts.
4. Conversational investigation has moved from concept to shipping product, reducing buyer education for a dedicated casework layer.

Catalyst. Trustfull's launch and the source-reported rise of AI-enabled fraud show that investigation workflow, not just detection accuracy, has become the urgent budget line for teams drowning in linked-signal reviews.

The product plugs into existing KYB, risk-scoring, CRM, ticketing, and web-intelligence tools rather than replacing them. For each merchant application, it pulls contact points, website metadata, IP history, prior applications, analyst notes, and third-party checks into one case graph that highlights linked entities and contradictory evidence. Analysts can ask natural- language questions such as whether a new application shares infrastructure with previously rejected merchants or whether the domain and phone behavior match the claimed business. The system generates a human-review memo with cited evidence, recommended next actions, and decision rationale that can be stored for audit and partner-review purposes. Over time, the company can train workflow-specific playbooks on which evidence patterns actually predict post-approval losses or chargebacks.

What's different. Most fraud vendors sell point checks or broad risk scores, while internal teams still build the actual case in spreadsheets and ticket comments. This company wins by becoming the investigation system of action for a single painful workflow: merchant onboarding under fraud pressure. Its defensibility comes from cross-tool integrations, historical decision graphs, and a corpus of linked-evidence playbooks that improve analyst throughput and explainability together, which is harder for any one signal vendor to replicate.

Jobs to be done

flowchart LR
  Buyer[Merchant risk leader] --> Pain[Manual linked-signal investigations]
  Pain --> Product[Merchant onboarding case OS]
  Product --> Outcome[Faster approvals with fewer bad merchants]

Executive takeaways

• The strongest near-term pain is not finding one more fraud score; it is collapsing merchant-review casework that still spans spreadsheets, Slack, processor alerts, and ad hoc web research into one explainable workflow.
• The beachhead is commercially real but narrow: UK/EU merchant-acquirer investigation software looks like a roughly $9M-$21M ARR wedge, so the venture case depends on expanding into adjacent fraud and compliance workflows after winning onboarding.
• Competitive whitespace exists between signal vendors such as Trustfull and broader merchant-risk systems such as Coris or Feedzai; the proposed startup must own the explainable merchant case graph and analyst workflow.
• Regulation and market fragmentation favor audit-ready notes, configurable playbooks, and geography-specific integrations over a generic AI copilot.

Market definition

The product category is merchant-onboarding investigation software for payment facilitators, acquirers, and adjacent PSPs: a system that pulls KYB, digital-footprint, processor, CRM, and prior-case data into one case graph so analysts can approve, pend, or reject merchants before activation.

Customer and buyer

The operational user is the merchant-risk or fraud-operations manager who supervises onboarding reviews and escalations; the economic buyer is usually a VP Risk, CRO, or GM of merchant acquiring who owns fraud losses, approval SLAs, and regulatory posture across payment operations. [8][10][11][20]

Buying triggers

• Suspicious-application spikes, expansion into higher-risk merchant categories, or industrialized fraud rings can swamp manual review queues and force a rethink of casework capacity. [7][18][29]
• Multi-processor growth exposes the limits of Slack, spreadsheets, and disconnected alerts, especially when analysts need a single merchant view across processors and geographies. [11][13]
• Risk-based payment controls and AML guidance increase the need for auditable rationales, structured delays, and defensible merchant decisions. [20][21][23][24]

Willingness to pay

Buyers can justify budget when a platform materially cuts review time, reduces manual documentation, and avoids losses from bad merchants getting live. The clearest public evidence is operational ROI: Coris references a two-thirds reduction in review time at Quilt, a 30% reduction at Zift, and materially lower documentation requests and fraud losses at Ignition, while Feedzai highlights false-positive reduction and analyst efficiency at Unzer. [10][11][12][13] [10][11][12][13]

Category dynamics

Growth signal 6.8% CAGR in EU electronic payment value from 2017 to 2021

Validation signals

• Trustfull raised €6M in 2025 to expand its European fraud-prevention platform
• TeamSystem deployed Trustfull to strengthen TS Pay merchant onboarding for SMB merchants
• Coris customer studies report 30% to roughly 67% review-time reduction plus lower losses and less documentation burden
• Fraud leaders continue to budget for identity risk tooling as organized rings drive attack volumes higher

Regulatory & technical constraints

• Merchant decisions need audit-ready rationales that align with UK and EU payment and AML guidance, especially when delaying or escalating suspicious activity.
• The product must integrate processor, CRM, KYB, and external-digital-risk data while preserving privacy, access controls, and human review.
• High-performing detection requires graph and link analysis across phones, emails, IPs, devices, and domains, but recommendations must remain explainable enough for analysts and auditors.

Coris is the closest direct "merchant risk operating system" competitor; Trustfull, SEON, and LexisNexis are stronger on raw digital-identity or link-analysis signals; Feedzai, Sardine, and Alloy are broader fraud and identity platforms; LegitScript is a merchant-policy and compliance specialist. That leaves room for a payfac-native investigator workspace that sits above existing vendors, assembles explainable evidence, and writes the analyst memo that current tools often leave to humans. [7][14][15][16][17][18][19][27]

Why incumbents do not win by default

• Processor and native acquirer tools. They control valuable transaction data, but customer references still describe fragmented alerts, limited merchant context, and weak cross-processor case assembly before teams adopt a dedicated workflow layer.
• Identity orchestration platforms. Platforms such as Alloy offer broad partner ecosystems and workflow engines, but their positioning is generic identity and fraud orchestration rather than merchant-underwriting-specific investigation playbooks.
• Digital signal vendors. Trustfull and similar vendors are strong at phone, email, IP, and domain checks, but the public messaging centers on signal access and AI summarization more than end-to-end merchant-review operations.
• Generic internal tooling. Spreadsheets, tickets, and chat channels are cheap defaults, but public case studies show they break under growth because they do not preserve a complete, auditable merchant record or consistent workflow.

Merchant Risk Case OS should start as an investigator workspace for UK and EU payment facilitators and merchant acquirers that onboard roughly 500-5,000 SMB digital merchants per month. The acute pain is analyst time lost assembling phone, email, IP, domain, website, KYB, CRM, and prior-application evidence before an approve, pend, or reject decision. The product should sit above existing signal vendors and processor tools, not replace them, and output an explainable merchant case memo with cited evidence and next-step recommendations. The daily champion is the head of merchant risk or fraud-operations manager, while budget typically sits with a VP Risk, CRO, or GM of merchant acquiring responsible for fraud losses, approval SLAs, and audit posture. Research supports a real but narrow beachhead, with an estimated $21.2M TAM, $9.3M SAM, and $1.6M year-3 SOM for the initial UK/EU payfac-acquirer wedge. That makes the first market commercially credible, but not large enough on its own for a venture-scale outcome without adjacent workflow expansion after onboarding proof. Go-to-market should therefore begin with paid pilots on one onboarding queue, triggered by suspicious-application spikes, new higher-risk merchant categories, or new-processor and cross-border launches that create immediate backlog pressure. The core risk is that Coris, Trustfull, processors, or broader fraud platforms become "good enough" unless the startup proves materially faster review time, cleaner audit notes, and faster deployment with existing tools. The biggest evidence gaps are which KPI unlocks budget first in practice and how many UK/EU accounts truly have enough analyst density to support a dedicated category.

Problem

• Merchant-risk teams at UK and EU payfacs still investigate suspicious onboarding applications across KYB vendors, processor tools, CRM notes, spreadsheets, and prior-case searches, so approval queues grow faster than analyst headcount.
• Those teams also need audit-ready rationale for approve, pend, and reject decisions, but current workflows leave evidence fragmented across screenshots, tickets, and ad hoc notes.

Solution

• Overlay the existing stack with a merchant case workspace that pulls phone, email, IP, domain, website, KYB, CRM, and prior-application signals into one explainable case graph.
• Generate analyst-ready approve-pend-reject recommendations and cited case memos that stay human-approved on day one and can be stored for audit, partner review, and later model tuning.

Why we win

• The product wins the workflow that point-signal vendors and processors still leave manual: assembling linked merchant evidence, queueing reviews, and writing the final decision memo.
• Each reviewed case compounds a merchant entity graph, integration footprint, and outcome-linked playbook library that becomes more valuable than any single signal source.

Milestones

flowchart LR
  Wedge[Merchant onboarding wedge] --> MVP[Case graph MVP]
  MVP --> Proof[Faster reviews and audit notes]
  Proof --> Expansion[Adjacent merchant risk workflows]

Founding team

Experiment roadmap

Risk assessment

What must be true

• At least 35 UK/EU payfac or acquirer accounts have enough merchant-risk analyst density and onboarding volume to support a dedicated production contract.
• A limited-connector deployment can reach first value in 45 days or less for the beachhead workflow.
• Paid pilots convert to production above 50% when the product shows at least 30% lower review time and cleaner audit notes.
• Buyers will fund an investigation workspace before incumbent signal vendors or processors bundle a sufficient alternative.
• Expansion into at least one adjacent merchant-risk workflow can increase ACV within 12-18 months of the first deployment.

Open diligence questions

• Which KPI actually creates budget urgency: review-time reduction, lower fraud losses, faster merchant activation, or audit readiness?
• How many target accounts truly match the assumed 500-5,000 monthly onboarding volume and 20-50 analyst team profile?
• Can a browser-overlay or limited-connector product deliver enough ROI before full processor integration?
• Why do customers choose this over Coris, Trustfull, Feedzai, or internal case-management tooling?
• What evidence types most often change a merchant decision in first-line underwriting versus escalation review?

Model sanity

• Revenue engine. Base-case revenue is driven by reaching 6 production customers by Q4Y2 and then lifting ACV inside a few logos through adjacent workflow expansion rather than chasing dozens of new accounts.
• Must go right. The limited-connector deployment has to stay under 45 days so paid pilots convert before implementation drag turns the business into a services-heavy model.
• Model breaks if. If buyers only fund review-time savings as a nice-to-have or sales cycles stretch past 120 days, the downside case pushes cash toward the last few quarters of buffer.
• Next-round proof. The next financing is justified by proving 6 production customers, repeatable sub-45-day deployments, and at least 2 adjacent-workflow expansions by Q4Y2.

Scenarios

Sensitivity

flowchart LR
  TargetAccounts[Target accounts] --> PaidPilots[Paid pilots]
  PaidPilots --> ProductionCustomers[Production customers]
  ProductionCustomers --> ExpansionWorkflows[Adjacent workflows]
  ExpansionWorkflows --> Revenue[Subscription and usage revenue]
  Revenue --> GrossProfit[Gross profit]
  GrossProfit --> Cash[Cash and runway]

Flags: The beachhead is intentionally narrow, so the model relies on ACV expansion and not just logo count to become attractive enough for the next round. · Gross margin only reaches the 70% target if limited-connector deployments stay repeatable; bespoke processor work would quickly erode the base case. · Cash bottoms near $630K in the base case, which is workable but leaves little room for a long pilot-to-production delay without slowing hiring or raising earlier.

• Vendor adjacency. Existing fraud-data and KYB vendors may add lightweight copilots and bundle them into current contracts. Mitigation: Focus on cross-vendor case orchestration, audit trail quality, and workflow outcomes that single-signal tools cannot deliver alone.
• Integration drag. PSPs often have messy internal systems and custom review flows, which can slow deployment and value realization. Mitigation: Start with browser overlays and a limited connector set for the first onboarding queue, then expand integrations after proving SLA impact.
• False-confidence risk. Analysts may over-trust generated recommendations and miss nuanced fraud patterns if the product is positioned as autonomous. Mitigation: Keep humans in the approval loop, expose cited evidence behind every recommendation, and optimize first for investigation speed rather than auto-decisioning.