The payment decision layer

Between the moment a payment is proposed and the moment money actually leaves, something has to decide whether the transaction should be allowed at all. Historically that decision was often embedded inside other products — an AP system, a bank, a fraud tool, or an internal automation. As initiation becomes more automated and more varied, it makes increasing sense to treat this step as a layer in its own right.

Definition

A payment decision layer is a system that sits between initiation and execution. It evaluates the payment request together with additional context, applies policy, and returns a final decision on every request while preserving a record that can be used for audit.

This map uses four outcomes:

Allow — the request passes policy and is sent to execution.
Hold — the request is suspended pending more information or later re-evaluation.
Block — the request violates a hard rule. No payment executes. The decision and the reason are recorded.
Escalate — the request is outside the scope of automatic approval and is routed to a designated human or system for explicit sign-off.

A decision layer may also return reason codes, policy-version pointers, and signed decision receipts.

What it is not

Not a fraud engine. Fraud scoring is probabilistic, advisory, and usually works on card-network signals after the card has already been presented. See Why fraud tools are not payment decisioning.
Not an orchestrator. Orchestration decides how to route an already approved payment. A decision layer decides whether the payment should happen.
Not a bank, processor, or issuer. It does not hold funds, run rails, or maintain a direct network relationship.
Not a generic authorization system. A generic policy engine answers questions like "can user U perform action A on resource R?" A payment decision layer understands counterparties, amounts, currencies, mandates, sanctions status, cost centers, and how these interact in a money-movement event.

Typical inputs

The payment request — amount, currency, counterparty, rail.
The identity of the initiator — agent, automated workflow, service account, or human.
Mandate or consent evidence where available (for example, AP2 mandates).
Operator policy — thresholds, allowed and blocked counterparties, cost-center rules.
External signals — sanctions lists, KYC / KYB status, wallet risk, fraud score as one input among others.
Context — time, frequency, and earlier decisions on related payments.

Typical outputs

One of the four outcomes.
A reason code.
A pointer to the policy version that produced the decision.
A signed record that can be used for audit, reconciliation, or disputes.

Why this layer is becoming visible now

When initiation mostly came from humans inside specialized tools, the decision logic could stay hidden inside those tools. When requests come from agents, automated workflows, ERP runs, API calls, and protocols, a common decision interface becomes easier to justify.

Several adjacent developments — mandate concepts in network protocols, the argument for separating decisioning from execution in architecture, and new agent-identity schemes — are inputs this layer consumes. They are not the layer itself.

Where Froddy fits

Froddy belongs to this layer: it sits before payment execution, applies policy to the request, and returns one of four outcomes with a reason code and an audit record. Execution, routing, and movement of funds remain in the client's existing infrastructure.

Change log

2026-04-18 — Initial publication.