Noetfield Banking

Govern agent-initiated payments and account actions — identity, policy, limits, confirm, verify, receipts — on licensed rails.

Request vendor pack One-pager (PDF) money_v1 scorecard Trust Center index Security OpenAPI

Agent → ABCP (identity · policy · limits · confirm · verify · receipt) → Partner rail

Hard boundary. Noetfield is not a chartered bank and not a money transmitter. ABCP is an assurance layer on licensed partner rails. This site publishes doctrine, schemas, and evaluation twins — not live settlement.

Overview

ABCP sits between the agent tool loop and licensed money rails. It binds identity, enforces policy, caps spend, challenges high-impact actions, verifies rail outcomes, and emits receipts. Fail-closed.

What we are

Agent Execution Assurance for money-moving agents (Banking 3.1–3.2).

What we are not

Not a chartered bank
Not a card network
Not a money transmitter by ourselves
Not an AI-native bank charter product

Thesis

Agents will move money. Rails will exist. Trust is the product.

Control model

Decision pipeline: identity · policy · limits · confirm · verify · receipt. Controls below map to Tier-1 vendor questionnaires.

Identity & delegation

Every tool call binds agent_id ↔ principal (human or service) ↔ tenant_id. Delegation grants are scoped, time-bound, and revocable.

Q · Who is the agent acting for?Q · Can grants be revoked instantly?

Dual control / confirm for high-value

Above-threshold payments and revoke-class tools require a bound, single-use confirm token issued outside the model turn.

Q · What requires a second factor?Q · Is confirm replayable?

Segregation of duties

Admin (policy/limits), operator (run agents), and auditor (read receipts) are separate roles. Operators cannot rewrite policy; admins cannot silently erase audit.

Q · Who can change limits?Q · Who can suspend agents?

Idempotency & replay protection

Client idempotency keys are required on write tools. Duplicate keys return the original receipt; confirm tokens are single-use.

Q · What happens on network retry?Q · Can a confirm be reused?

Kill switch / suspend-agent

Admin suspend immediately fails closed for that agent_id. Pending confirms are invalidated.

Q · How fast can we stop an agent?Q · Does suspend cover in-flight confirms?

Immutable audit (receipts)

Every money-adjacent decision emits a receipt. Accepted outcomes require required checks to pass. Signed receipt profile: receipt-money-v1.

Q · Can we export for examiners?Q · Are receipts tamper-evident?

Fail-closed decisioning

Missing policy, schema failure, over limit, failed confirm, or unverified rail status → rejected or error — never soft-accepted.

Q · What is the default on dependency failure?

Risk & controls

Laws enforced on every money-adjacent decision.

Receipt law. Every money-adjacent decision emits a receipt; accepted only if required checks pass.
Fail-closed. Missing policy, bad schema, over limit, failed confirm, or unverified rail → no successful money claim.
Least privilege. Allowlisted tools only; JSON Schema with additionalProperties false before side effects.
Confirm high impact. Above-threshold and revoke-class tools need bound, single-use confirm tokens.
Tenant isolation. Identity, memory, cache, vectors, and account refs are namespaced; cross-tenant is a hard error.
Rail separation. ABCP assures; licensed partners move value.
Eval ≠ exec. Public evaluation kits prove the pattern; live money stays on the private control plane.

Compliance posture

Honest scope — partner-held licenses; ABCP does not claim bank charter, money-transmitter license, PCI certification, or OSFI approval unless separately evidenced.

Full compliance page Threat model & redaction