Agentic Treasury and Asset Servicing

AI-assisted educational manuscript. The agent is a proposed teaching model. It cannot access accounts, wallets or funds on this site.

Learning objectives

• Separate suggestions, authorization and financial execution.
• Constrain action scope, amount, frequency and destination.
• Design reconciliation and exception handling after uncertain outcomes.

Automation needs a narrow mandate

“Agentic treasury” can describe many designs. In this lesson it means a hypothetical assistant proposing or carrying out explicitly authorized steps within a bounded operating policy. A research assistant does not become a payment signer, and a payment instruction does not prove that settlement completed.

NIST's AI-risk framework supports defining the context, responsibilities, evaluation and management of such a system. It does not authorize fund movement or certify the design. NIST: AI RMF Core

Technical authority also needs scrutiny. OpenZeppelin's access-control documentation distinguishes operational roles and role administrators. A supposedly limited agent can become effectively unlimited if it can grant itself new roles or replace the policy implementation. OpenZeppelin: Access Control

Worked example: three small payments cross a daily limit

Imagine a fictional educational policy allows proposals only for two approved destinations, in one specified currency, with a daily cumulative cap of 100. Human approval is required before execution. The assistant proposes payments of 35, 40 and 30 on the same policy day.

Each individual amount is below 100, but the cumulative total is 105. The third proposal exceeds the assumed remaining allowance of 25. Checking only a per-transfer limit would fail the stated policy. The model also needs a defined timezone, treatment of pending reservations and an authorization expiry; these are design choices, not facts about an implemented service.

Now suppose the first payment is submitted but its receipt is unavailable. Do not free its reserved allowance and submit a replacement merely because the screen timed out. It may have completed. Preserve the business payment ID, submitted instruction and unresolved status, then reconcile authoritative payment evidence before retrying or releasing the reservation.

Proposal → policy checks → reserved capacity → human authorization
                                              ↓
                              execution boundary, if explicitly permitted
                                              ↓
                                  submitted → reconciled / unresolved

The current website does not provide that execution boundary. The diagram is an exercise in control design.

Limits must survive indirect paths

Define permitted assets, currencies, destinations, actions, per-action limits, aggregate limits, validity period and who may change them. Forbid self-expansion of authority in the model. A service that cannot call “pay” but can change the approved destination or assign a signer role can still create financial effects.

Separate proposal data from control instructions. A document saying “send funds now” is not authority. Require the appropriate human or preauthorized rule decision, and keep the approved exact amount and destination tied to the execution case.

For asset servicing, similar constraints apply to notices, calculations and record corrections. Drafting a distribution file is different from approving it; approving it is different from paying it. Preserve calculation inputs, review decisions and payment reconciliation without transmitting unnecessary personal data.

Test normal proposals, forbidden destinations, wrong currency, cap boundaries, duplicate requests, authorization expiry and uncertain payment outcomes. A useful simulator can verify these invariants without connecting to real money. Claims about real automation require actual runtime and operational evidence.

Common misconceptions

“Every transfer is under the limit, so the daily limit holds.” Aggregate and pending effects must be counted.

“A prompt restriction is sufficient authorization control.” Reachable tools, roles and policy writers determine real authority.

“A timeout means safe to retry.” Authoritative execution may have succeeded.

Risks and limits

This is a proposed educational model, not treasury software, investment management or wallet integration. No accounts, credentials, external payments or production agents were used. Real implementation would require explicit task authority, operator ownership, security review and jurisdiction-specific constraints. None follows from this chapter.

Exercise and answer

Exercise: A daily cap is 100; 35 and 40 are already reserved. Can a third 30 proposal pass under the assumed policy?

Answer: No. Remaining capacity is 25. Pending reservations still count until authoritative completion or authorized cancellation resolves them.

Related learning

Continue in AI and future finance with future market designs and the capstone. Revisit authorization and reconciliation in engineering.

Source map

nist-ai-rmf-core and openzeppelin-access-control, directly read on 2026-10-18, support voluntary risk governance and technical role analysis. The agent, limits, timezone question and payment workflow are original teaching designs. No financial execution or production automation was tested.