ZenPropTech Review: Ownership, Portability & Due-Diligence Passport
ZenPropTech makes unusually strong public claims about customer ownership, migration and API access. PFV keeps it on verification hold because contracting-identity/jurisdiction questions remain unresolved. Those two facts must stay separate.
Buyer Dependency Layer
| Dependency layer | Current evidence state | What the buyer still needs to establish |
|---|---|---|
| Exit & portability | partial | Provider states buyer ownership of customer/trade data and migration of key datasets; full outbound exit schema, timing, retention and deletion terms still need contract confirmation. |
| Control & authority | unknown | Exact breach, risk-rule override and payout approval authority is not publicly established in the reviewed evidence. |
| Integration dependency | partial | Provider states APIs for multiple operational datasets/events; read/write scope, credentials, rate limits and termination portability require contract confirmation. |
| Operational continuity | partial | Migration without disrupting active traders and high-availability claims are provider-stated; remedies, rollback and post-termination support require contractual evidence. |
See the Buyer Dependency Model methodology →
PFV Due-Diligence Passport
| Area | Evidence state | Buyer implication |
|---|---|---|
| Customer / trade data ownership | Provider-stated | FAQ states the buyer owns brand, domain, customer database and trade data. Contract language still governs enforceable rights. |
| Technology / code ownership | Mixed / provider-stated | Public material uses strong ownership language. Buyers should distinguish delivered custom code from hosted services, third-party licences and infrastructure accounts. |
| Migration scope | Provider-stated | FAQ says migrations can include trader accounts, historical trades, payout history and affiliate data. |
| API access | Provider-stated | Provider lists APIs for trader data, trade events, payouts, KYC status and affiliate tracking. |
| Full exit export | Partial / unknown | Migration scope is described, but complete outbound schema, format, retrieval period and deletion sequence should be contractual. |
| Hosting / availability | Provider-stated | Provider says scalable high-availability cloud and region selection are available; buyers should request contractual availability and DR details. |
| Dependency concentration | Medium-high | Website, dashboard, CRM, risk, integrations, KYC and hosting can be delivered as one stack. |
| Risk / payout authority | Unknown | Exact breach override and payout approval rights are not established by the public material used here. |
Why ownership claims need contract decomposition
“You own the platform” can mean different things: source code, a licence, deployed binaries, repositories, cloud accounts, configuration, data, branding or only custom deliverables. A buyer should list each asset separately and state what survives termination.
Verification hold
PFV's existing hold remains because public identity/jurisdiction signals require re-verification before a qualified introduction path can be restored. No ownership, API or migration claim overrides that control.
What buyers should request
- Full contracting entity, registration and governing jurisdiction.
- Repository/source-code delivery and licence terms where ownership is promised.
- Cloud/infrastructure account ownership and credential transfer.
- Complete export schema for traders, trades, accounts, breach state, KYC, payouts and affiliates.
- Termination, retrieval and deletion timelines.
- SLA, backup, disaster recovery and incident-response evidence.
- Risk-rule override and payout approval authority.
Use the data ownership guide, vendor lock-in guide and Propriotec vs ZenPropTech comparison for context.