At a glance
What you need to know.
A financial-services AI workflow should begin with a bounded task, approved data and an explicit authority boundary. This engineering guide examines evidence gathering and reviewed proposals, with controlled execution and recovery. Applicable policies and regulatory obligations must be established by the organization's accountable specialists for its actual jurisdiction and service.
Choose a task that can be evaluated
Start with a task such as preparing a cited case summary or collecting approved evidence for a reviewer. Define its permitted sources, output fields and acceptance rule. Distinguish this assistance from decisions that alter customer entitlements, balances or transactions. The organization needs to determine its applicable policy, approval and retention requirements with authorized specialists; an engineering pattern cannot establish compliance. A narrow evidence-preparation task lets the team evaluate usefulness and error behavior before considering additional discretion or destination writes.
Separate evidence access from decision authority
An agent that may read a document does not automatically have authority to act on the account described in it. Map requester identity, role, record ownership and permitted purpose for each source and tool. Keep controls server-enforced, including background processing. Give the reviewer the relevant evidence without exposing unrelated customer information. A shared index needs the same scope rules as the underlying repository. Test attempts to access another customer or an unauthorized field, and reject them independently of the model's explanation or confidence.
Preserve source and interpretation separately
Store references to the approved source version and distinguish extracted facts from generated interpretation. A summary should identify missing evidence and uncertainty rather than fill gaps with plausible text. Define which statements need citations or structured reconciliation. If the source changes, determine whether a pending proposal needs review again. Keep sensitive raw material out of general logs and limit access to stored outputs. The ability to reconstruct what a reviewer saw is a design requirement that affects data storage, retention and versioning from the beginning.
Make human review control the exact proposal
Prepare a concrete draft or change with target record, affected fields, source evidence and the intended operation. Validate the reviewer's authority and bind approval to that version and relevant target conditions. A changed amount or customer record should not inherit an unrelated earlier approval. Support rejection and correction with reasons. In an illustrative case-review workflow, the model highlights a discrepancy, a reviewer decides its meaning and a separate authorized operation records the accepted outcome. No model assessment should silently become permission to move funds or change account access.
Reconcile effects after ambiguous delivery
Even an approved operation can encounter a lost response or partial completion. Use the destination's actual reference and duplicate rules; confirm accepted state before replaying a write. A model cannot infer whether an external transaction committed from a timeout alone. Keep requested, approved, submitted and accepted states distinct. Assign an exception owner who can inspect the authoritative destination using approved access. Test cancellation, expired approval and changed inputs as well as the normal path. Recovery must follow the business system's contract rather than improvising a compensating action.
Evaluate safety, usefulness and operational capacity
Build cases with complete evidence, missing records, conflicting sources, malicious instructions and unavailable tools. Measure accepted task quality, unsupported statements, unauthorized attempts, review effort and elapsed completion. Review performance across the task categories and languages actually used. Account for reviewers and exception handling in capacity planning; generating proposals faster can overload a controlled decision queue. Release one approved category with a stop mechanism and explicit ownership. State executed evidence and remaining assumptions separately, including provider behavior and organization-specific policy requirements.
Keep evidence and execution under separate authority
An AI-generated proposal is not authorization to perform a business action. Validate record ownership, tool arguments and the permitted operation outside the model using the actual requesting identity. Restrict tools to the agreed task and require a reviewed path for privileged or irreversible decisions. Treat retrieved documents and tool responses as untrusted content that can contain misleading instructions. Preserve the evidence a reviewer needs with appropriate access, rather than exposing raw sensitive inputs in general logs. OWASP's prompt-injection guidance supports layered controls; retrieval, fine-tuning and a carefully written prompt do not establish an enforceable security boundary.
Before you start.
- Which bounded assistance task is permitted?
- Who establishes applicable policy and regulatory obligations?
- Are source access and action authority separate?
- Is review bound to the exact proposal and target conditions?
- Can ambiguous delivery be reconciled at the authoritative destination?
Common questions.
Does this architecture make a financial AI workflow compliant?
No. It describes engineering controls and acceptance questions. The organization must establish applicable obligations, permitted use and approval requirements with authorized specialists, then verify the actual implementation and operating procedures against them.
What is a sensible first agent task?
A bounded task such as gathering approved evidence or preparing a cited case summary for an authorized reviewer can be evaluated before granting writes. Define sources, output criteria, missing-evidence behavior and review ownership. Validate access independently from the model.