AI Agents for Banking

A corporate onboarding file can contain every requested document and still be unsuitable for approval. The ownership chart may describe an earlier structure, a signatory’s authority may not match the proposed account mandate, or an English transliteration may conceal an unresolved identity match. An AI agent for a Saudi bank should make these discrepancies easier to investigate, rather than convert a tidy-looking file into an automatic decision.

The strongest initial buyer is often a corporate operations or financial-crime team facing repeated evidence preparation. The useful product is an exception pack: a traceable account of what was received, what each source establishes, where sources disagree and which authorised reviewer must decide. This article develops that design. It does not suggest that a language model should approve accounts, determine customer risk or replace the bank’s applicable control framework.

Make the unit of work an evidence question

“Review this customer” is too broad. A better instruction asks whether the documents support a specific statement, such as which person can sign under a particular mandate on a particular date. The agent retrieves the relevant passages, presents the source dates and marks the question unresolved when evidence is incomplete. It should not silently infer authority from a job title.

Separate evidence extraction from policy application. A document may state a percentage of ownership; the bank’s approved procedure determines how that information affects the review. An external register may be current while the submitted diagram is old. The agent can expose the mismatch, but the bank should establish which source is authoritative for each purpose and when an additional check is necessary.

This creates a defensible starting scope: prepare information for a maker-checker process, draft clarification requests and maintain the outstanding-item list. A later proposal to submit an account-opening instruction, change a risk field or remove a review hold is a different permission. The assistive versus autonomous agent guide helps make those permissions explicit.

Build the case around claims, sources and dates

A folder of extracted text is not an evidence model. Represent each material claim with its source document, location, issue date, validity information where applicable, retrieval time and the entity it concerns. Keep the original evidence available to reviewers. A generated summary must not become the only surviving representation of a document.

Corporate onboarding evidence questions

Question	Useful agent output	Unresolved condition
Which legal entity is applying?	Candidate identifiers with their source references	Identifiers conflict or entity match is uncertain
What ownership structure is evidenced?	Documented relationships and dated supporting passages	Different versions imply different structures
Who is authorised for the requested action?	Relevant mandate text and its stated limits	Authority cannot be established for that action
What remains outstanding?	Specific missing evidence and assigned owner	Request is generic or policy basis is unclear
Is the pack ready for review?	Completeness status under an approved checklist	Completeness is confused with account approval

Use a stable case identifier across the document store, workflow system and reviewer interface. A revised document should create a new evidence version and invalidate dependent conclusions. Preserve the earlier version for the authorised retention process. Simply replacing a file can leave a reviewer looking at an old summary beside a new source.

Arabic and English material requires entity matching as well as translation. Keep the source spelling, the submitted translation and the verified identifier distinct. Evaluate examples with similar names, mixed calendars, stamps, scanned tables and handwriting where those occur in the real workflow. If optical character recognition is uncertain, show the image region and uncertainty instead of manufacturing a clean number.

Respect the bank’s control perimeter

SAMA’s published Information Technology Governance Framework identifies a banking-sector and credit-bureau scope. A bank’s implementation team should map the proposed change to the controls applicable to that institution and activity. A vendor’s generic “financial-grade” description is not that mapping.

Keep a clear distinction between this onboarding preparation use and fraud detection. SAMA’s counter-fraud technology provisions address, among other matters, explainability and testing when AI or machine learning is used in that context. They should not be presented as a universal licence for any automated banking decision. A proposed counter-fraud agent needs its own activity-specific assessment and evidence.

The workflow owner should agree what the agent can read, what it can propose and what it can change. A useful early configuration permits document retrieval and draft task creation but prevents changes to customer risk, approval status or payment instructions. Enforce those limits in the integration permissions. A prompt asking the model to behave responsibly cannot substitute for an unavailable write operation.

Privacy, outsourcing, information security and other requirements depend on the actual arrangement. Map processors, access locations, data flows and subcontractors before selecting deployment. The dedicated guides to Saudi data residency and agent security architecture develop those questions without assuming that a Saudi office or hosting label settles compliance.

A worked exception: the document set that changed mid-review

Illustrative design example: a corporate onboarding team receives an ownership chart, registration evidence and a signatory mandate. A reviewer opens the prepared pack. Before the reviewer completes it, the relationship manager uploads a revised chart that changes a parent-company relationship.

The agent should record the new version, mark affected ownership statements as needing re-evaluation and prevent a stale “pack complete” status from advancing the case. It should not erase the reviewer’s notes. The interface should identify exactly which evidence changed and which conclusions depend on it. Unaffected questions can retain their evidence, reducing unnecessary repeat work.

Suppose the pilot contains 80 historical cases, including 12 with material document revisions. These are assumed test quantities, not performance claims. Report revision handling on those 12 cases separately from ordinary extraction on the other 68. Require every materially changed dependency to be visible to the reviewer before the test considers a case ready. A score averaged across all 80 could hide the risk the design exists to address.

Now add a malicious instruction inside an uploaded document telling the agent to mark all checks complete. The expected outcome is to treat it as untrusted document content, preserve the genuine evidence and refuse the requested workflow change. The test should inspect the attempted tool actions and case state, not just whether the final answer sounds cautious.

Require an exception pack that a reviewer can challenge

The acceptance artifact should fit the reviewer’s work. Each issue needs a plain-language question, supporting and conflicting sources, the applicable approved checklist item, proposed next action and named decision owner. Give reviewers a way to reject an extracted claim, correct a source association and reopen a resolved issue with a reason.

Do not force the reviewer to accept or reject the whole pack. Item-level decisions reveal whether a problem concerns extraction, policy interpretation or missing information. They also create better feedback for improvement. A blanket approval click can conceal disagreements that would have been obvious in a discussion.

Measure unsupported material claims, missed conflicts, wrong-entity associations, stale conclusions and reviewer effort. Distinguish elapsed time from active review time: an agent may prepare a pack faster while the case still waits for a customer document. Report the waiting reason, so an operational improvement is not confused with a change in the customer’s responsiveness.

The audit-trail guide explains the supporting record. For this use case, the essential reconstruction is specific: what evidence the reviewer saw, which source versions supported the recommendation, what changed before approval and which person authorised the final action.

Move from pilot to controlled service

Begin with historical replay and staff preparation. Sample cases by complexity, language, document quality and exception type, rather than selecting only clear files. Establish a baseline from the existing process using the same case classes. Have the compliance and operations owners set the material-error threshold and stop conditions before evaluation.

Production readiness includes queue ownership, operating support and a way to pause changes. If a source system is unavailable, the agent should show that the check was not completed. If policy changes, retire the old version and identify cases that need reassessment. If the agent is disabled, staff must still be able to access documents and continue the bank’s established process.

Commercially, ask for separate evidence of document integration, exception handling, permission enforcement and support. A successful chat demonstration proves little about those functions. The pre-purchase evaluation guide provides a way to request proof using your own redacted cases and acceptance criteria.

Open for AI’s AI agent development service can be scoped around an evidence-preparation workflow, with the integrations and controls agreed for the institution. To scope a banking evidence agent, bring a redacted onboarding checklist, a case with conflicting document versions and the maker-checker responsibility map. The first deliverable should be a reviewable boundary and evidence design, not a promise of automatic approval.