Author your risk rules. Version them. Replay any decision for the examiner.

What you enforce

Transaction and transfer caps, per-account limits, velocity rules, fraud counters and circuit breakers, lending and approval logic, pre-trade order validation. All as state-aware policy, which is what a stateless rule engine cannot do without bolting on a database: a rule that knows this is the fifth transfer this hour, not just that one transfer arrived.

What a rule looks like

State-aware, versioned, and replayable. This one reads the running daily total and routes the call to a human once the cap is reached.

constants:
  daily_refund_cap: 5000

state_models:
  agent:
    key: "{{ event.data.agent_id }}"
    buckets:
      refunds_today:
        type: fixed_window     # resets daily at 00:00 UTC
        window: "24h"
        timezone: "UTC"

rules:
  # Every refund the agent issues adds to today's running total.
  track_refund:
    all:
      - path: "event.type"
        op: eq
        value: "agent_action"
      - path: "event.data.action"
        op: eq
        value: "issue_refund"
    effects:
      state_changes:
        agent:
          change_buckets:
            refunds_today: "{{ event.data.amount }}"

  # Once today's refunds reach the cap, the next one needs a human.
  refund_over_daily_cap:
    all:
      - path: "event.type"
        op: eq
        value: "agent_action"
      - path: "event.data.action"
        op: eq
        value: "issue_refund"
      - path: "state.agent.buckets.refunds_today"
        op: gte
        value: "{{ constants.daily_refund_cap }}"
    effects:
      verdict: flagged
      priority: 100
      actions:
        - action: hitl/create_case
          params:
            queue: "refund-review"
            priority: 100
            decision_types: ["approve", "reject"]
            timeout_duration: "2h"
            timeout_decision: "reject"

Prove it to the regulator

Deterministic rules replay exactly on the version that was live; where a decision used a model or a human, the full trace records the inputs, the output, and who or what decided. Either way, when an examiner asks why a transaction was approved or held, you answer from the record, not from memory. This is the part most teams cannot produce, and it is built in here, not bolted on.

Where Swiftward fits

If you are an AI-native startup, you may have no risk tooling at all, and Swiftward is the layer you start with. If you are a bank, you already run AML screening and model-risk management, and Swiftward governs the AI-action and agent-decision layer those do not reach, feeding your existing SIEM and audit. Either way the boundary is the same, and we are clear about it: Swiftward enforces and proves the rules you and your AML and KYC stack define; it is not an AML data vendor or a KYC provider. That is the scope that survives a procurement review. See where we sit relative to your fraud and AML stack.

It connects however your decisions already flow: a direct call to the decision engine from your own code, synchronous or asynchronous; the tool layer an agent already uses (MCP), with nothing the agent can see; or an industry protocol like FIX for trading and order flow. Pick what fits; the engine underneath is the same.

Standards and regulations

Swiftward is the control-and-evidence layer over your AI agents' decisions. It is not a model-validation or model-risk-management tool, and it does not make you compliant; it gives your function the technical controls and the evidence these regimes ask for.

For financial crime, we map to FFIEC BSA/AML, FinCEN, FATF, and Wolfsberg for the controls you enforce.