Skip to content

Fraud detection · decisioning · operations

Every check earns its place. Policy has the last word.

FRAPE scores payments, sign-ups, logins, profile changes and payouts through a fixed sequence of gates. Rules and cached data settle most events cheaply; paid enrichment and the Decision Core run only when they could change the outcome; a deterministic policy makes every final call.

Become a design partnerSee the decision flow
How an event moves through FRAPEEvents pass through five gates in order: rules, cache, providers, Decision Core and policy. A terminal rule can decide immediately. Cached data can make provider calls unnecessary, and the Decision Core is skipped when rules are already confident. The policy gate always issues the final verdict: approve, challenge, review or decline.cache hitrules confidentterminal rule → decided nowVERDICTapprove · challengereview · declineRules01Cache02Providers03Decision Core04Policy05

Built for

  • Payment service providers
  • Marketplaces
  • Fintech & lending
  • Digital goods & gaming
  • Subscription businesses

Platform

Score, understand, operate — in one tenant-isolated platform.

Three families of capability share one data model, one audit trail and one policy engine.

Score

One synchronous call returns a decision, a 0–100 score, stable reason codes and the rules that fired. Rules and cached data settle what they can before anything is paid for.
Rules, policy & the Decision Core

Understand

Resolve the person behind an event through strong aliases, watch sliding-window velocity per card fingerprint, device, email hash and IP, and see shared-device networks.
Identity & velocity

Operate

Alerts, case queues with SLAs, analyst feedback that becomes labels, lists, backtests, signed webhooks and an append-only audit trail of every change.
Cases & fraud operations

Coverage

One API for every risky moment in an account’s life.

Each moment is an event type on POST /v1/score, scored against the same identity and the same policy.
  1. 01

    Sign-up

    signup

    Catch throwaway and repeat identities before they get an account: alias reuse, device history and list hits.

    Use case
  2. 02

    Login

    login

    Spot takeover attempts from new devices, unusual networks and bursts of attempts across accounts.

    Use case
  3. 03

    Profile change

    account_update

    Treat changes to email, phone or payout details as the high-risk moments they are, with step-up when needed.

    Use case
  4. 04

    Payment

    payment

    Score a purchase by card fingerprint, BIN, device and velocity — never by card number, which is refused.

    Use case
  5. 05

    Payout

    payout

    Hold money movement that does not fit the identity’s history before it leaves the platform.

    Use case

Design principles

Four things FRAPE will not trade away.

  1. 01

    Cost-aware by construction

    Terminal rules and cached data handle what they can first. Paid enrichment and the Decision Core run only when the answer could still change.

  2. 02

    Explainable to the line

    Each decision records the rules that matched, whether the Decision Core was consulted and why not, and the policy version that decided.

  3. 03

    Private by default

    Card numbers are refused at the door. Contact data is stored as keyed hashes. The Decision Core sees a minimised, whitelisted state only.

  4. 04

    Degrades, never fails open

    If the cache, a provider or the Decision Core is unavailable, scoring continues and missing data is never read as safe. Failure never auto-approves.

How it works

Cheap checks first. Expensive ones only when they matter.

Every request walks the same ordered path. Each stage can end the work early; none of them can override the policy.
  1. Validate request — POST /v1/score · schema · no card numbers
  2. Pre-rules #1 — terminal hard rulesterminal hit → decide now
  3. Cache & local data — cache → local reference dataall local → zero provider calls
  4. External providers — missing capabilities only · paralleltimeout + circuit breaker each
  5. Features + pre-rules #2 — velocity · identity · signals
  6. Decision Core (advisory) — only when rules can’t settle itskipped or unavailable → policy
  7. Policy engine — deterministic · owns the decision
  8. Decision — APPROVE · CHALLENGE · REVIEW · DECLINE

  • Terminal rules stop known-bad traffic

    No provider call, no Decision Core call, a decision in the same request.

  • Cached and local data before the network

    A request served entirely locally makes zero external calls.

  • Decision Core only for the unclear middle

    Skipped when rules are confident, disabled, over budget or unavailable.

Walk through the full flow

Solutions

Shaped to the risks of your business.

The same platform, configured with different rules, lists and thresholds per tenant.

Payments & PSPs

Score card-not-present payments for many merchants from one platform, with each merchant kept in its own tenant and its own policy.

Typical risks

  • Card testing bursts
  • Stolen-card purchases
  • Merchant-specific risk appetite

Signals FRAPE uses

  • Card-fingerprint velocity
  • BIN country against IP country
  • Device reuse across accounts

Events scored

  • payment
  • account_update
Details for Payments & PSPs

Developers

One call. A decision you can explain.

  • Synchronous JSON over HTTPS with an API key, idempotency keys and problem+json errors.
  • Every response carries reason codes, matched rules and the policy version that decided.
  • Cards travel as fingerprint, BIN and last four. Card numbers are rejected with a 400.
Read the API example
score a payment
curl https://api.frape.io/v1/score \
  -H "Authorization: Bearer $FRAPE_API_KEY" \
  -H "Idempotency-Key: order_81723" \
  -d '{ "type": "payment", "external_id": "order_81723", ... }'

→ { "decision": "CHALLENGE", "score": 58,
    "reasons": ["new_device_for_account"],
    "model_called": true, "policy_version": "pol_2026_09_28_3" }

Economics

What it costs to run, published in the open.

Engineering cost estimates come from a versioned cost model and a deterministic calculator. They are not commercial pricing.

Engineering cost estimate

$0.59

per 1k transactions · 10M transactions / month · base case

Model 2026.10.0, as of 2026-10-01. Not commercial pricing.

Infrastructure, Decision Core and provider costs are modelled separately, with every input labelled as a published price, a list-price estimate or an engineering assumption. Change the volume and the mix in the calculator and see what moves.

Security & privacy

Collect less. Isolate everything.

No card numbers, ever

Payloads containing a card number or CVV anywhere are refused. Cards are known only by fingerprint, BIN and last four.
Data handling

Tenant isolation in depth

Row-level security on every tenant table, plus application checks on every request. Other tenants’ records simply do not exist to you.
Isolation controls

A minimised Decision Core

The Decision Core receives a whitelisted state — no card data, secrets, raw email, raw phone or full IP — and its output is advisory only.
Model inputs

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.

Become a design partnerSee the decision flow