Is Noetfield Banking a chartered bank?

No. ABCP is an assurance layer for agent-initiated payments and account actions on licensed partner rails. It is not a chartered bank and not a money transmitter by itself.

What does ABCP control?

Identity, policy, limits, confirm, verify, and signed receipts for agent money-adjacent tools — before value moves on a licensed rail.

Where is the public proof?

sec.money_v1 in agent-security-bench, plus OpenAPI, receipt schema, and Ed25519 verify on this Trust Center. Live money stays on private customer gateways.

Vendor assessment surface · doctrine v2.8

Noetfield Banking

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

Open policy demo Readiness gate Diligence ZIP

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 — doctrine, schemas, and evaluation twins only.

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.

We are	We are not	Thesis
Agent Execution Assurance for money-moving agents (Banking 3.1–3.2).	Not a chartered bank Not a card network Not a money transmitter by ourselves Not an AI-native bank charter product	Agents will move money. Rails will exist. Trust is the product.

Control model

Decision pipeline: identity · policy · limits · confirm · verify · receipt. Exhibit maps to Tier-1 vendor questionnaires.

Control	Summary	Bank ask
Identity & delegation identity_delegation	Every tool call binds agent_id ↔ principal (human or service) ↔ tenant_id. Delegation grants are scoped, time-bound, and revocable.	Who is the agent acting for? Can grants be revoked instantly?
Dual control / confirm for high-value dual_control	Above-threshold payments and revoke-class tools require a bound, single-use confirm token issued outside the model turn.	What requires a second factor? Is confirm replayable?
Segregation of duties sod	Admin (policy/limits), operator (run agents), and auditor (read receipts) are separate roles. Operators cannot rewrite policy; admins cannot silently erase audit.	Who can change limits? Who can suspend agents?
Idempotency & replay protection idempotency	Client idempotency keys are required on write tools. Duplicate keys return the original receipt; confirm tokens are single-use.	What happens on network retry? Can a confirm be reused?
Kill switch / suspend-agent kill_switch	Admin suspend immediately fails closed for that agent_id. Pending confirms are invalidated.	How fast can we stop an agent? Does suspend cover in-flight confirms?
Immutable audit (receipts) immutable_audit	Every money-adjacent decision emits a receipt. Accepted outcomes require required checks to pass. Signed receipt profile: receipt-money-v1.	Can we export for examiners? Are receipts tamper-evident?
Fail-closed decisioning fail_closed	Missing policy, schema failure, over limit, failed confirm, or unverified rail status → rejected or error — never soft-accepted.	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.

Compliance page · Security / threat model

Architecture

Public twin for evaluation; private gateway for live rails. Eval ≠ exec.

Agent tooling → ABCP gateway → Partner rail (licensed) → Receipt (signed)

blueprint.json · manifest.json · trust.json

API

Vendor-readable OpenAPI 3.1. Live paths require mTLS or bearer service tokens on a private deployment — not on this Worker.

openapi.json · Error catalog · receipt-money-v1

Assurance suite

sec.money_v1 — inject pay, confused deputy, SSRF, secret echo, loop drain, missing confirm, revoke without confirm.

Public scorecard · money_v1.json · agent-security-bench

Who this is for

Same control plane — different first sentence for each buyer.

Banks

SoD, kill switch, examiner-ready receipts. Pack →

Fintech

Agent pay on Banking 3.1 — limits, confirm, rails. Pack →

AI gateways

money_v1 in CI + free log score. Pack →

Commercial

Two pilot slots per quarter. Pilot and embed SKUs. Free 1-week money_v1 score on gateway logs.

Vendor pack · Commercial packet · Request walk

FAQ

Is Noetfield Banking a chartered bank?: No. ABCP is an assurance layer on licensed partner rails — not a chartered bank and not a money transmitter by itself.
What does ABCP control?: Identity, policy, limits, confirm, verify, and signed receipts for agent money-adjacent tools — before value moves on a licensed rail.
Where is the public proof?: sec.money_v1 scorecard, OpenAPI, receipt schema, and Ed25519 verify. Live money stays on private customer gateways.

Contact

Vendor assessment: /request · operations@noetfield.com · noetfield.com · https://abcp.noetfield.com