Platform
Everything between an event and a defensible decision.
FRAPE combines decisioning, identity, velocity, case management and fraud operations around one policy engine. Each module has one job, and the order they run in is fixed.
Rules & policy
Declarative rules, versioned policies, one deterministic answer.
Rules are JSON condition trees in three stages. A policy version is immutable once published, and exactly one is active per organisation.
- Three stages
- Hard pre-rules that may end the flow, signal rules that produce facts and score, and post-policy rules that combine everything.
- Deterministic
- The same inputs and policy version always produce byte-identical outcomes. Evaluation is pure and side-effect free.
- Backtests
- Replay a draft policy over historical events with the same engine before you activate it.
- Four decisions
- APPROVE, CHALLENGE, REVIEW or DECLINE — with a risk level and stable reason codes.
Decision Core
An advisory second opinion for the cases rules cannot settle.
The Decision Core is FRAPE’s advisory scoring component. It is called only when the rules score falls in the uncertain band and the organisation allows it; the policy decides what its answer means.
- Only when needed
- Skipped after a terminal rule, when rules are already confident, when disabled, over budget, or when its circuit breaker is open.
- Minimised input
- A whitelisted state built field by field: no card data, secrets, raw email or phone, full address or full IP.
- Validated output
- Answers are schema-checked; malformed or out-of-range answers count as unavailable.
- Never auto-approves
- If the Decision Core is unavailable, the organisation’s fallback applies — review, challenge, decline or rules-only.
Conditional enrichment
Cache first, local data second, providers last.
An enrichment plan lists only the capabilities an event needs. Each is answered from cache, then local reference data, and only what is still missing goes out.
- Zero-call path
- When every capability is served locally, the request makes no external provider call at all.
- Parallel and bounded
- Provider calls run in parallel, each with its own timeout and circuit breaker.
- Graceful degradation
- A failed provider marks its features unavailable. Rules never match on unavailable data.
- Credentials stay sealed
- Provider credentials live in a secret manager, are write-only in the console and are never returned by any API.
Identity & velocity
Know who is behind the event, and how fast they are moving.
Events resolve to identities through strong aliases. Velocity counters track activity per dimension over sliding windows.
- Strong aliases
- Account, external id, card fingerprint, email and phone resolve in a fixed precedence. Contact data is stored as keyed hashes.
- No weak merges
- Identities are never merged on weak signals such as a shared IP address. Merges are recorded and reversible.
- Sliding windows
- Counts and amounts per card fingerprint, device, email hash, IP, identity and account over minutes, hours and a day.
- Network views
- See identities that share devices or cards to uncover rings.
Alerts & cases
Turn risky decisions into worked cases and better labels.
REVIEW and DECLINE decisions raise alerts. Analysts group them into cases, work them to a resolution, and the resolution flows back as labels.
- Deduplicated alerts
- One alert per identity and rule per hour, not one per event.
- Case lifecycle
- Open, investigating, resolved as fraud or legitimate, or closed — with assignment, comments and SLA due dates.
- Feedback as labels
- Resolving a case labels its events; chargeback and fraud reports arrive through the feedback API.
- Deterministic summaries
- Case summaries are generated from templates, so they say exactly what the data says.
Fraud operations
The controls a fraud team needs every day.
Lists, webhooks and an audit trail, administered through a role-based console.
- Lists
- Block and allow lists for devices, card fingerprints, hashed emails, IPs and ranges, countries, BINs and accounts.
- Signed webhooks
- Scored events, new alerts and case updates delivered with HMAC signatures, retries and SSRF protection.
- Audit trail
- Every administrative change is recorded with before, after and actor; reading the audit log is itself audited.
- Roles and MFA
- Organisation admins, analysts and viewers, with mandatory TOTP for administrators.
Multi-tenancy
Built for many organisations from the first table.
Every tenant-scoped table carries an organisation id protected by database row-level security, with application checks on top.
- Isolation in depth
- Requests run in a transaction scoped to the caller’s organisation; cross-tenant lookups return not-found.
- Per-tenant policy
- Thresholds, fallback modes, allowed countries and retention are organisation settings.
- Test keys
- Test API keys swap providers and the Decision Core for deterministic fakes and flag events as test traffic.
- Simple runtime
- A small set of workloads, one database, one cache and one queue — modules, not microservices.
Design partners
Help shape what FRAPE decides next.
We are working with a small number of teams who score payments, sign-ups, logins or payouts and want decisions they can explain line by line. Bring your rules and your edge cases.