Prop Firm Software Vendor Due Diligence: Verify the Business Risk, Not Just the Features
The hardest technology problems often appear after signing: data that cannot be exported, payout authority that is unclear, integrations controlled by one vendor, weak exit rights or an SLA that is only a marketing target. PFV separates evidence, public transparency and operational dependency instead of hiding them inside one synthetic score.
Three signals that must stay separate
| Signal | What it answers | What it does not mean |
|---|---|---|
| Evidence confidence | How strong and current is the supporting evidence? | High evidence does not automatically mean low risk. |
| Public transparency | How much can a buyer verify before a sales call? | Low public disclosure does not prove poor operations. |
| Operational dependency | How difficult is replacement if the vendor relationship changes? | High dependency can be rational if the provider also carries valuable operational burdens. |
The PFV 10-layer due-diligence model
- Economics: setup, recurring, usage, account, revenue/profit share, third-party costs and real cost curve.
- Ownership & exit: customer/trader data, code, branding, configuration, export scope, format, retention, termination and transition assistance.
- Reliability: contractual SLA versus target, uptime evidence, backup, restore, failover, disaster recovery and incident escalation.
- Security: encryption, MFA/2FA, RBAC, audit logs, tenant isolation, DDoS protection, backup and incident response.
- Risk authority: which system decides breach state, who can override rules, whether decisions are reconstructible and who controls payout approval.
- Money layer: PSP ownership, reserves, chargebacks, payout rails, merchant accounts, fund flows and who carries payout liability.
- Integration & openness: APIs, webhooks, sandbox, SDKs, KYC/payment/trading-platform integrations and whether integrations survive a switch.
- Operations & scale: account limits, automation, multi-brand support, observability, support capacity and workflow scaling.
- Compliance & governance: KYC/AML tooling, data residency, market-data licensing, auditability and AI/data-use governance where relevant.
- Vendor/company risk: concentration, critical third parties, continuity, acquisition/shutdown risk, replaceability and source/code escrow where appropriate.
Evidence states
| State | Meaning |
|---|---|
| Verified / primary-source | Current contract, terms, technical documentation or other direct evidence supports the field. |
| Provider-stated | The provider publishes the claim, but PFV has not independently measured it. |
| Unknown / not publicly evidenced | No sufficiently specific current public evidence located. |
| Conflicting | Current public sources disagree; written clarification is required. |
Evidence hierarchy
| Evidence | Best use |
|---|---|
| Signed agreement / order form | Commercial obligations, liability, ownership and scope |
| Terms / SLA / DPA | Service, legal, security and data conditions |
| Live acceptance test | Current production capability |
| Technical documentation | API, webhook, security and integration behavior |
| Pricing / product page | Public commercial and product signal |
| Case study / testimonial | Reference-check lead, not independent proof |
Turn every claim into a buyer test
“Real-time risk” should become a timed breach scenario with a reconstructible audit record. “99.9% uptime” should become a question about the contractual measurement window, exclusions, remedies and historical performance. “You own your data” should become a tested machine-readable export of traders, accounts, trades, breach state, payouts, KYC status, affiliates and configuration.
Dependency concentration deserves its own review
A vendor that supplies CRM, trading integration, risk, KYC, payments, payouts and capital may reduce operational burden while increasing the cost of replacement. PFV therefore records dependency separately from product quality. Buyers should identify which contracts and credentials they control directly, which are vendor-mediated, and what has to move during an exit.
The PFV Due-Diligence Passport
Matcher-eligible provider profiles now use a structured passport that records evidence state for data ownership/export, technology ownership, SLA, APIs, migration, dependency concentration and risk/payout authority. The passport is not a ranking score. It is a map of what is evidenced, provider-stated or still needs written confirmation.
Diligence log
- Claim and buyer impact.
- Source URL/document and evidence type.
- Date checked.
- Contractual versus marketing/provider-stated.
- Open question and written vendor response.
- Contract clause/order-form reference when material.
- Change since previous snapshot.
Continue with the procurement hub, demo checklist, contract checklist and migration checklist.
FAQ
Is an unknown field a red flag?
No. It means PFV does not have enough current public evidence to classify the field. Material unknowns should be resolved in writing before purchase.
Why not give every provider one score?
A single number hides important trade-offs. A vendor can be highly transparent yet create high dependency, or disclose little publicly while operating well. PFV keeps evidence, transparency and dependency separate.