Froddy Documentation

Froddy sits before the payout, takes one request, and returns allow / hold / block before money moves.

Froddy is a pre-payout control layer for automated payouts. It helps stop duplicate payments, broken limits, and payout logic errors before money leaves. The final action stays with your backend.

What Froddy does

Checks a request before the payout is sent
Returns one of three verdicts: allow / hold / block
Catches duplicates, rule errors, and logic failures
Maintains a single decision log before money moves

What Froddy does not do

does not send money
is not a bank, PSP, or payout rail
does not replace KYC/AML
is not a full anti-fraud replacement

How it works

Your backend sends a request to Froddy before the payout.
Froddy checks the rules and request context.
You receive allow, hold, or block in response.
The final action — send the payout, put it on hold, or stop it — stays on your side.

What to send in a request

Send only the data needed for the decision. By default, Froddy does not require raw PII. You can use hashed or pseudonymous IDs, along with technical and business fields that help verify duplicates, limits, and rules.

payout / transfer identifier
account / user / partner identifier
amount and currency
route / method / destination type
rule-relevant metadata
idempotency or external reference
timestamp / event context

What verdicts the API returns

allow — the request can proceed
hold — the request should be stopped for additional review or manual decision
block — the request should be rejected

Quick start

Open Demo and review the request and response format.
Create an account and get access to the test environment.
Add one pre-payout call before sending money.
Handle allow / hold / block on your side.
Connect webhook notifications if needed.

Request example

POST /v1/evaluate
Authorization: Bearer <api_key>
Content-Type: application/json

{
  "external_id": "payout-8821",
  "entity_id": "partner-hashed-a3f9",
  "amount": 1500.00,
  "currency": "USD",
  "destination_token": "dest-token-b7c2",
  "method": "bank_transfer",
  "metadata": {
    "route": "outbound",
    "idempotency_key": "idem-20240306-8821"
  }
}

Response example

{
  "verdict": "allow",
  "decision_id": "dec-0f3a8b",
  "reason": null,
  "rules_evaluated": 4,
  "logged_at": "2024-03-06T12:00:00Z"
}

For hold or block verdicts, the reason field contains the identifier of the rule that triggered.

Notifications

Froddy supports a webhook-first scenario for notifications about events and changes related to request processing. Use webhook as the primary public way to receive these signals.

Data and decision log

Froddy helps build a decision log before money moves. By default, you can work without raw PII using hashed or pseudonymous identifiers. This simplifies data minimization and audit of payout decisions.

If you need a DPA or a description of data processing, contact us.

FAQ

Is this anti-fraud?

No. Froddy does not replace a full anti-fraud system. It covers pre-payout checks: duplicates, limits, logic errors, and hold mechanics before money moves.

Is raw PII required?

Not necessarily. In most scenarios, hashed or pseudonymous IDs and the technical fields needed for rule checks are sufficient.

Who makes the final payout decision?

The final action stays with your backend. Froddy returns allow, hold, or block before money is sent.

How do I get started?

Start with Demo, then create an account and add one pre-payout call before sending money.