Real-time circuit breaker for automated merchant settlements and disbursements.
This page is for VP Operations, Risk & Compliance Leads, and Heads of Engineering at payment processors, acquirers, and payout platforms who manage automated merchant settlements and disbursements.
If your team is responsible for calculating and executing merchant payouts — and you don't have a pre-execution checkpoint that limits blast radius — this is relevant.
For product fundamentals (what Froddy is, how rules work, how enforcement operates), see Docs. This page covers how Froddy applies specifically to payment processors.
| Risk class | What happens | Blast radius |
|---|---|---|
| Cascading duplicate payments | A bug in settlement logic causes the same batch to execute twice, or individual payments to duplicate | Loss doubles with every cycle until the bug is caught — often hours later |
| Merchant velocity spike | A merchant's payout requests jump from 10/day to 200/day due to a system error or exploit | Cumulative exposure grows linearly until someone intervenes |
| Settlement concentration | A single merchant accumulates disproportionate daily settlement volume — exceeding normal ratios | Full daily exposure in one counterparty; hard to spot without pre-execution ceilings |
| New merchant anomaly | A recently onboarded merchant reaches unusually high settlement volumes before any track record is established | No baseline makes manual detection unreliable |
Froddy does not detect the intent behind these risks. It limits blast radius by flagging anomalies in amount, velocity, and daily exposure before money moves.
Settlement calculated Froddy evaluates Disbursement executes
[Settlement Engine] ──→ [ Froddy ] ──→ [Banking Rail / Ledger]
evaluates in ms
allow / hold / block
Froddy sits between your settlement engine (after amounts are calculated and approved) and the banking rail or ledger entry. One API call before each disbursement. In observe-only mode, your settlement flow continues uninterrupted — Froddy logs without blocking.
Abnormal single settlement. A merchant who typically receives $5,000–$20,000 settlements has one calculated at $180,000 — a potential calculation error or data anomaly. → Caught by: R-COHORT (single transaction anomaly)
Daily exposure concentration. A single merchant's cumulative settlements for the day reach $500,000 against a normal baseline of $80,000. → Caught by: R-CEIL (daily ceiling)
Duplicate settlement cascade. A bug in the batch processor triggers 60 settlement records for the same merchant in 30 minutes. Each is individually normal, but the count is not. → Caught by: R-VEL (velocity spike)
New merchant, fast ramp. A merchant onboarded 5 days ago is already receiving $200,000/day in settlements with no transaction history to support that volume. → Caught by: R-CEIL (daily ceiling)
Sub-merchant source clustering. In a payment facilitator model, 4 distinct sub-merchant accounts are submitting settlement requests from the same source hash — a sign of shared infrastructure or misconfiguration. → Caught by: R-DEDUP (source hash deduplication)
These are starting points — observe-only mode exists to validate them against your actual traffic.
| Rule | Parameter | Suggested start | Why |
|---|---|---|---|
| R-COHORT | hold_usd |
$50,000 | Above typical single merchant settlement for mid-size processors |
| R-COHORT | block_usd |
$250,000 | Well beyond normal single settlement events |
| R-CEIL | daily_ceiling_usd |
$150,000 | Above typical daily volume per merchant; adjust for your distribution |
| R-VEL | max_count / window |
30 txns / 1h | Settlement batches may be larger; accommodate normal batch sizes |
| R-DEDUP | max_entities |
4 | Less critical for PSP than CPA; relevant for payfac sub-merchant models |
Product defaults for reference: R-COHORT hold $25K / block $100K, R-CEIL $50K, R-VEL 20/1h, R-DEDUP 3 entities. See /docs Rules Reference.
Note: Payment processors typically have a wider spread in settlement sizes than CPA networks. Expect to use entity overrides more aggressively — high-volume merchants will need custom ceilings.
Scenario A → ALLOW
Merchant_305 receives a $12,000 settlement. Daily total is $45,000, well below the ceiling. One of 8 settlements today — normal velocity.
Result: all rules pass → allow. Disbursement proceeds normally.
Scenario B → HOLD
Merchant_088 receives a $65,000 settlement — their largest this quarter. The hold threshold is $50,000.
Result: R-COHORT triggers → hold-for-review. In observe-only mode this is logged and an alert is sent. With active enforcement (available by arrangement), the disbursement would be queued for review.
Scenario C → BLOCK
A batch processing error generates 70 settlement records for Merchant_201 in 15 minutes. The block threshold is 60 (max_count 30 × block_multiplier 2).
Result: R-VEL triggers → block. In observe-only mode this is logged. With active enforcement (available by arrangement), the disbursements would be stopped.
An evaluation is particularly timely when:
Integration details: API Reference
entity_id (merchant ID), amount, event_id per settlement; device_hash recommended for payfac modelsFroddy is a circuit breaker for settlement execution risk, not a replacement for your compliance or underwriting infrastructure. See What Froddy Does — and What It Doesn't.
| Resource | Link |
|---|---|
| Product documentation | froddy.io/docs |
| API reference | froddy.io/api |
| Interactive demo | froddy.io/demo |
Ready to evaluate? Request an evaluation or try the demo.