Hira reconciles what your ramp instructed with what actually settled onchain, and runs sanctions, velocity and data-completeness policy on every order — continuously, out of band.
For neobanks, on-ramp providers and stablecoin-card fintechs moving customer money onchain — on your own contracts or an issuer’s rails.
None of these were exotic exploits. Monitoring that couldn’t keep pace with volume was the violation itself.
Reconciliation first, screening always — deterministic policy on every order, out of band, at any volume.
What you instructed versus what settled, matched per order by correlationId — the failure class wallet screening can’t see.
Explore the walkthroughEvery order ages against its settlement window, every float account against pending obligations — drift opens an exception before month-end finds it.
Explore the settlement queueVelocity and structuring typologies run per event, each breach landing with an owner and an SLA — a backlog can’t grow quietly.
Explore the exception modelBoth sides of every flow screened, and beneficiary data checked against policy — under EU TFR, every transfer, no de minimis.
Explore the policy packsWhen a policy breaks, Hira opens an exception: assigned to a person, governed by an SLA clock, escalated when it runs out. Every action is written to an immutable record your examiner can replay — a control, not a backlog.
Explore the exception modelThe board is a live queue of the gap between card money and chain money: unmatched orders, payouts aging past their window, float drifting under 100%. Each column carries its own SLA, so the oldest mismatch is always the loudest.
See how exceptions are workedNYDFS fined Block Inc.’s Cash App $40M for AML failures driven by rapid growth — a SAR backlog that swelled from 18,000 to over 169,000 alerts, and high-risk bitcoin flows proceeding without scrutiny. No exotic exploit: monitoring that couldn’t keep pace with volume was the violation itself.
Real incident. Illustrative detection — Hira did not monitor this system.
Emit an event when money moves in your backend — Hira handles reconciliation, evaluation and escalation from there. Fire-and-forget and fail-open: nothing in your payment path ever waits on Hira.
Read the SDK docshira.track('payout', { amount: '4180.00', asset: 'USDC', toAddress: '0x8f3C…9aB1', customerId: 'cus_82914', beneficiaryInfo: { name: 'J. Okafor', accountRef: 'ext-wallet', }, correlationId: 'ord_58291', });
Two feeds. Your backend emits events through one server-side track() call — payouts, transfers, mints, redemptions, reserve moves, admin actions. Hira reads the chain independently and reconciles the two, then evaluates every event against your policies: thresholds, ratios, velocity, sanctions. Anything that crosses a line opens an exception with a named owner and an SLA clock.
Keep them — they screen counterparties against public chain data, and they’re good at it. They’re structurally blind to your own operations: your ledger, your payout instructions, your reconciliation state — all of it looks perfectly normal on chain. Hira compares your first-party backend events against independent chain state — the gap screening tools can’t see, because they never had your intent to compare against.
No — and that’s deliberate. Hira observes events and chain state out of band: it adds zero latency, never holds keys, and can’t fail closed on your flow. The SDK is fire-and-forget and fail-open — if Hira is ever unreachable, you lose visibility, not availability. Your existing systems keep deciding what moves.
Those watch fiat and app behavior, and they’re good at it. None of them reconcile what your backend intended against what actually settled onchain — and that gap is where the new failure class lives: settlement mismatches, payouts that never landed, float coverage drifting, duplicate sends after retries. Hira sits alongside your case manager as the chain-truth layer, not as its replacement.
Detective controls between your ledger and the chain — running before your next exam, not reconstructed for it.