Fraud Detection Engine — Terms & Conditions

Liability framing and acceptable use for the PlatformXe Fraud Detection Engine.

These Terms govern your use of the Fraud Detection Engine (the "Engine") — the synchronous decision endpoint, rule engine, screening service, device registry, identity verification adapters, cases workflow, and federation push functionality together — as part of the PlatformXe service.

By calling any /api/v1/fraud/* endpoint or any identity verification endpoint after enabling the Detection Pack addon, your organisation accepts the most recently published version of these Terms. Click-through acceptance via POST /api/v1/fraud/terms/accept is required for the cases UI and identity verification surfaces; calls to those endpoints are blocked with FRAUD_TERMS_REQUIRED until acceptance is recorded.

Current version: 2026-05-03-v1.0. Bumping the version invalidates prior acceptances and re-prompts the operator.

1. The control-plane principle

The Engine is a fraud control plane — the layer between your application and the action it protects. Every verdict the Engine renders is informational: it is a recommendation derived from the rules, signals, and screening results you have configured. Your application keeps full control over what action is taken on the basis of any given verdict.

To make this explicit, every /api/v1/fraud/decide response includes a mandatory notice field. You agree:

The Engine NEVER decides whether to commit a transaction, freeze an account, send a wire, lock a user, or take any other action against your customers.
Your organisation is the decision authority of record for every such action.
You will not represent to your customers, regulators, or any third party that PlatformXe took, or directed, the action.

2. Acceptable use

You may use the Engine to:

Render real-time fraud verdicts on actions in your own application.
Screen names against the global sanctions / PEP / adverse-media lists ingested by PlatformXe and against your own tenant lists.
Verify identity documents and biometrics for customers WHOSE explicit, informed consent you have collected and recorded.
Federate fraud rules and tenant lists across organisations in a federation group you own.

You may NOT use the Engine to:

Screen, profile, or surveil individuals who are NOT party to a service relationship with you.
Make automated decisions that materially affect individuals without a meaningful human-in-the-loop review where local law requires one (e.g. GDPR Art. 22, where applicable).
Resell raw screening results to third parties.
Reverse-engineer, scrape, or attempt to reconstruct the canonical sanctions / PEP / adverse-media lists from screen results.
Persist sanctions / PEP / adverse-media data outside of the Engine (your screen calls return at most 25 hits per query precisely to discourage bulk extraction).

3. Data, retention, and confidentiality

3.1 What we store

Asset	Where	Retention
Decisions (`fraud_decisions`)	Encrypted at rest. PII excluded from `context`.	90 days (Pro) / 7 years (Enterprise)
Screen results (`fraud_screen_results`)	Sanitised query + hits.	90 days
Cases (`fraud_cases`)	Reviewer notes + verdict trail.	7 years (regulatory minimum)
Identity verifications	Raw provider response envelope-encrypted via KMS; metadata only when KMS is unconfigured.	7 years
Identity DLQ	Captured original request + provider chain failure reasons.	90 days
Audit logs	Append-only. Permission + decision change logs separate.	90 days (Pro) / 7 years (Enterprise)

3.2 PII handling

The Engine accepts PII in identity verification requests (BVN, NIN, biometrics, account numbers). PII is NEVER stored in the clear when KMS is configured — every raw provider response is wrapped in an envelope-encrypted blob keyed by the per-tenant KMS key.
Screening queries accept names + dates of birth + identifiers. We hash names for trigram matching but do NOT log the raw query alongside the hit set.
Webhook payloads are sanitised to exclude PII; subscribe to events for change notifications, not for data extraction.

3.3 Cross-border transfer

PlatformXe operates from the European Economic Area and serves customers globally. Identity verification provider chains are country-scoped (Phase 6F.5) — a Nigerian KYC verification calls Nigerian providers, a Kenyan one calls Kenyan providers. Routing across borders is limited to the Engine's own infrastructure (database, KMS, observability) and is governed by our Data Processing Addendum.

4. Liability

4.1 Verdict reliance

You acknowledge that:

Fraud verdicts are probabilistic. False positives and false negatives WILL occur.
Sanctions and PEP lists are refreshed daily on a best-effort basis. A name appearing in a published list after our last refresh, or a name removed from a list before our next refresh, may not be reflected in screen results until the next cron run.
Identity verification providers can return incorrect or outdated data. The Engine layers fallback chains and circuit breakers to mitigate single-provider failures, but cannot guarantee correctness.

To the maximum extent permitted by law, PlatformXe is NOT liable for:

Losses arising from your reliance on a single verdict, screen result, or verification.
Losses arising from a false positive that prevented a legitimate transaction.
Losses arising from a false negative that allowed a fraudulent transaction.
Losses arising from the unavailability of an upstream provider, regardless of cause.

4.2 Indemnity

You will indemnify PlatformXe against claims by individuals whom you screened, verified, or made automated decisions about, where:

You did not collect their explicit, informed consent.
You used the Engine in violation of Section 2 (Acceptable Use).
You represented to the individual that PlatformXe took or directed the underlying action.

4.3 Service availability

PlatformXe's standard SLA applies to the Engine. The Engine's /decide endpoint targets sub-100ms p95 latency under normal load; the screening endpoint targets sub-80ms p95 against free public lists. Service Level Credits are governed by your underlying PlatformXe agreement.

5. Federation

If you push fraud rules or tenant lists from a parent organisation to members of a federation group (Phase 6G):

You represent that you have authority to do so on behalf of every member organisation.
Push is operator-initiated, not automatic. Each push is recorded in federation_sync_logs with direction='push' and the initiating organisation id.
Pushed rules become "owned" by the recipient organisation — they are local fraud_rules rows with createdBy='federation:<owner>', and the recipient can locally edit, archive, or override them.

6. Acceptance, version bumps, and termination

6.1 Click-through

Acceptance is recorded against your organisation via POST /api/v1/fraud/terms/accept with the current published version. The acceptance row carries the user identifier you supply (acceptedBy) and the timestamp.

6.2 Version bumps

PlatformXe may revise these Terms. Bumping the version invalidates prior acceptances; the cases UI and identity verification surfaces will block again with FRAUD_TERMS_REQUIRED until you re-accept. Read the current version via GET /api/v1/fraud/terms/status.

6.3 Disabling the addon

Disabling the Detection Pack stops billable fraud:* and identity:verify calls but does NOT delete already-stored decisions, screen results, cases, or identity verifications. Retention windows continue to apply.

6.4 Termination

Either party may terminate use of the Engine in accordance with the underlying PlatformXe agreement. On termination, your data is retained for the retention windows in Section 3.1 then deleted; export is available via the standard data-export workflow before termination.

7. Operational status

We maintain a public status page at https://status.platformxe.com that surfaces:

Per-(country, provider) circuit breaker state for identity verification.
Per-source freshness for sanctions / PEP / adverse-media lists.
Per-region availability for the /decide and /screen endpoints.

For incident notifications, subscribe to the page or the equivalent webhook events.

8. Changes to these Terms

These Terms are versioned. The version string surfaces in the acceptedVersion field of the status endpoint. The change log lives at the foot of this page; we will notify Detection Pack tenants by email at least 14 days before a version bump takes effect, except for security-driven changes which take immediate effect with concurrent notification.

Change log

Version	Date	Summary
`2026-05-03-v1.0`	2026-05-03	Initial publication (Phase 6H).