Balance checks, daily limits, and corridor blocks evaluated deterministically, with the failing check named in the response.
Limit logic duplicated between the ledger service and the API gateway
Changing a threshold means a deploy, and no audit trail of who changed it
Ops has no way to preview what a limit change would decline
Approve a withdrawal only when the account has the funds, is within its daily limit, and is in good standing.
A **withdrawal** is approved
if §withdrawal.funds is valid
and §withdrawal.limit is valid
and §withdrawal.account is valid.
withdrawal.funds. A **withdrawal** passes funds_check
if the __amount__ of the **withdrawal** is less than the __available_balance__ of the **account**.
withdrawal.limit. A **withdrawal** passes limit_check
if the __withdrawn_today__ of the **account** + the __amount__ of the **withdrawal** is less than or equal to the __daily_limit__ of the **account**.
withdrawal.account. A **withdrawal** passes account_check
if the __status__ of the **account** is equal to "active"
and the __frozen__ of the **account** is equal to false.
Change the policy, change the input, evaluate. The same engine your application would call.
Policy
Input
Transaction Limits
ComplianceClear a payment when it stays under the reporting threshold, avoids blocked corridors, and keeps the day's cumulative total in range.
Transaction Fraud Flag
FinanceFlag a transaction when the amount is unusually high and the location does not match the account.
API Rate Limiting
Access ControlAllow a request only if the account has not exceeded the monthly call limit for their plan.
We will implement your first policy with you.
Send us a rule you currently keep in application code and we will show you what it looks like as a versioned, traceable policy.
Talk to us