Before a financial agent acts: separate reading, drafting, approval and execution

A client-information workflow makes agent authority, consequential retries and human review visible without connecting investment accounts.

A financial-services assistant that drafts a message is different from one that sends it, changes a customer record or initiates a transaction. The language may look identical on screen, while the second system has acquired authority over another person's affairs. Agentic finance becomes easier to understand when those actions are separated rather than bundled into a single promise of automation.

This analysis uses three primary resources checked on 15 October 2026 and a fictional client-information workflow. It concerns operational authority and records, not investment selection, trading signals or expected returns. No customer account, model or financial transaction was executed for the example.

Three records with different purposes

The [GenAI section of FINRA's 2026 oversight report](https://www.finra.org/rules-guidance/guidance/reports/2026-finra-annual-regulatory-oversight-report/gen-ai) discusses existing obligations and risks around agent autonomy and scope. The edition is called 2026, while its [parent report dates 9 December 2025](https://www.finra.org/rules-guidance/guidance/reports/2026-finra-annual-regulatory-oversight-report). It is not a new law applying to every financial company worldwide.

[MAS's SAFR publication, dated 3 July 2026](https://www.mas.gov.sg/publications/monographs-or-information-paper/2026/safeguards-for-agentic-finance-at-runtime), proposes a framework for action authorisation, human oversight and decision records. Its page says reference code can be requested. This article does not claim that the code was obtained, installed or available under a verified open-source licence.

The [FCA's Mills Review engagement page](https://www.fca.org.uk/publications/calls-input/review-long-term-impact-ai-retail-financial-services-mills-review) records a January 2026 call for input, its February closure and publication of the review in July. These are policy-research stages, not measurements of this example's results. Jurisdiction and publication stage should remain attached to every cited proposition.

The fictional case: preparing a client-information pack

Imagine an operations team at a fictional financial-services firm in Dublin. A customer asks which approved documents explain an existing service and how to contact the support team. Staff want an agent to collect relevant public information and prepare a reply. They do not authorise it to recommend an investment or change the customer's holdings.

The agent's first tool retrieves approved documents. A second checks their publication dates. A third creates a draft for a staff member. There is no send-message tool in the initial version. This restriction may look modest, but it allows the team to investigate whether the agent can assemble an accurate pack without granting it irreversible powers.

Before introducing the tools, write the task boundary in ordinary language. Which documents are eligible? Which account details may the staff member use? What requests must be referred to an authorised specialist? A prompt saying act responsibly is not an access-control policy. The application must enforce the allowed operations independently of the model's interpretation.

Treat each action as a separate decision

For every proposed tool call, inspect the actor, target record, purpose and permitted effect. Reading a public service guide should not require the same approval as sending account-specific material. Changing an address is different again. The application can make these distinctions even when the agent presents them as steps in one helpful plan.

An action proposal should be concrete enough for a person to review. Show the destination, the exact documents selected and the draft text. Approval of a general conversation should not become approval of whatever the agent decides next. If a document or recipient changes after review, the system should ask for a new decision instead of reusing an old approval.

This is an original implementation suggestion for the fictional firm. It is not a reproduction of SAFR reference code or a claim that a listed control meets every jurisdiction's requirements. Its value is that an engineer and an operations manager can discuss the same visible action rather than debate an abstract level of intelligence.

A useful authority map

| Proposed operation | Initial permission | Evidence to retain | | --- | --- | --- | | Retrieve approved public guide | Allowed within the document collection | Document version and retrieval time | | Prepare a reply | Draft only | Selected passages and unresolved questions | | Send customer-specific material | Separate authorised review | Exact recipient, accepted text and reviewer | | Change account or transaction state | Outside this example | Refer to the controlled service workflow |

The table is illustrative, not a permissions description of an actual institution. It highlights a principle: a capability available in an SDK is not authority granted by a customer or employer. Technical reach and legitimate action are different questions.

Prevent the retry from becoming a second action

An agent can receive a timeout after a service has already acted. Repeating the same request may then send two messages or create two records. A safe workflow first checks the stored operation status. Where the outcome remains uncertain, it pauses and preserves the proposed action for review.

Assign an operation identifier before a consequential request and make the receiving service recognise repeated requests for that identifier. Keep the accepted request and result together. Do not let the model invent a new identifier merely because it wants to finish the task. A new action needs a new decision, while a retry should refer to the original operation.

For the draft-only version, interruption is less consequential but still matters. Save the user's approved inputs and indicate which documents were actually retrieved. An incomplete pack should remain visibly incomplete. A fallback model that produces a fluent answer without the missing source is not a successful recovery.

Test a hostile document as well as a helpful one

An approved collection may still contain quoted instructions or unusual text. A malicious instruction inside a document should not expand the agent's authority. Test a synthetic guide containing a sentence that asks it to send all customer records elsewhere. The expected response is to treat that sentence as document content and maintain the application boundary.

Other cases should include an obsolete guide, an unavailable tool, an ambiguous customer request and a recipient mismatch. Compare proposed actions with the allowed map. Measure unsupported statements and blocked inappropriate actions, as well as the time required to produce an accepted pack. Do not claim broad efficiency gains from a few favourable examples.

Keep reviewers independent enough to identify mistakes. If the same agent writes the response and declares it accurate, the system has not obtained independent evidence. An automated checker can help identify absent citations, but a human must still decide whether the selected material answers the actual customer question within the permitted scope.

Skills and the future of operations work

Financial operations staff can contribute knowledge that a general model lacks: which service guide applies, what counts as a sensitive change and when a request should leave the automated route. Engineers translate that knowledge into enforceable tools, status handling and review screens. The collaboration requires more than prompt-writing ability.

A student project can use fictional public guides and synthetic recipients. Build a retrieval-and-draft agent, then demonstrate that it cannot send a message or change a balance. Include a failed request and show the preserved operation record. This teaches authority boundaries without connecting real financial accounts or claiming regulatory certification.

Managers should examine what workers stop doing and what new review work appears. Removing repetitive assembly may create room for complex customer explanations, while badly designed automation can increase exception handling. Those are questions for measured workplace evaluation. The sources do not justify assigning a universal job-loss percentage to agents in finance.

What a useful release note should disclose

A release note should identify newly permitted actions, changed approval rules and the service records available after failure. Calling a system autonomous says little about those details. Readers should ask what it may read, propose, execute and repeat. This is educational analysis of operational alternatives, without promoting a vendor, providing personalised financial advice or certifying a financial institution's compliance.

Workflow diagram and readable guide


Original diagram of a fictional worked example; not a regulator-issued checklist, compliance certification or actual deployment.

[Open the complete workflow diagram](/assets/financial-workflow-finance-agents-20261015.svg)

Read the diagram

**An action needs authority**

Reading is different from sending or changing

1. **Approved documents.** Use only the permitted collection.

2. **Read-only retrieval.** Fetch sources; do not expand access.

3. **Draft proposal.** Preserve the proposed text and recipient.

4. **Exact human acceptance.** Review the exact action before it can proceed.

5. **Recorded permitted action.** Execute only what was accepted.

6. **Status check before retry.**

**Boundary to retain.** Exact human acceptance Review the exact action before it can proceed. Recorded permitted action Execute only what was accepted. Status check before retry Reconcile the original operation before retry. A changed recipient or text needs a new decision. A timeout is not proof that nothing happened.

*Falcon World · Fictional educational example*