AI Integration for Banking

For a Saudi bank, AI integration is an exercise in preserving account authority across systems. A service assistant may understand a customer's request while still lacking permission to retrieve the requested account, release a statement or change a servicing case. The useful design connects language interpretation to controlled banking functions, with evidence of which institution, customer, account and action were authorised.

This guide is for banking technology leaders, operations owners and control teams scoping an AI-assisted servicing integration. It uses a corporate statement-pack request to examine identity, entitlements, document delivery and reconciliation. It does not propose autonomous payments, credit decisions or investment advice. AI integration and delivery should be scoped around the actual bank applications and control environment.

Separate understanding the request from granting access

A customer may ask in Arabic for “the statements for our group for the last quarter”. That sentence leaves important questions open: which legal entities, which accounts, which quarter, what currency representations and which recipient? A model can help identify the missing information. It cannot establish the person's representation rights from the wording of the request.

Resolve the authenticated user, represented entity, authorised account set and permitted servicing action through the bank's authoritative controls. Preserve the requested purpose and channel where they affect the workflow. Do not expand a subsidiary's access because the customer uses a group brand name, or because an earlier conversation referred to additional accounts. Treat entity selection as a controlled step with an explicit result.

Read access, document release and case updates are different operations. A service identity permitted to retrieve a statement for internal review may not be permitted to send it to an external address. The integration access-control guide explains how to carry user and service authority through the workflow without replacing bank controls with a prompt.

Use a servicing envelope that survives every handoff

Proposed statement-pack integration envelope

Element	Meaning	Acceptance evidence
Request identity	A stable servicing reference linking preparation, approval and delivery.	Each downstream record can be traced to the intended request.
Customer and entity	The authenticated person and the legal entity they may represent.	Entitlement check identifies the authoritative source and its result.
Account scope	An explicit list of permitted accounts, without inferred group expansion.	Rejected or omitted accounts remain visible to the authorised operator.
Statement period	Exact start and end dates, supported statement type and relevant source version.	The generated pack matches the confirmed selection.
Release authority	Who may release which document to which approved destination.	Approval binds to the final pack and recipient, not an earlier draft.
Completion	The bank-defined evidence that the document is available through the intended channel.	Delivery and case-update states are recorded separately.

This envelope is a proposed application contract, not a banking standard or a claim that a named core platform exposes these fields. Map it to the bank's documented interfaces. Where an existing document service already performs statement generation, preserve that service's authoritative calculations and outputs. The language model should not reconstruct account balances from a partial transaction extract.

Worked example: one corporate request, two different entitlements

In an illustrative case, user U17 represents company C41 and requests a statement pack for accounts A6 and A9. The bank's entitlement service permits A6 for the selected purpose but returns no authority for A9. The assistant must not treat that as a technical inconvenience to bypass. It can prepare the permitted pack, if the bank's procedure allows partial fulfilment, or ask the customer to resolve the account selection.

Suppose the customer confirms A6 for 1 July–30 September 2026. The statement service produces document D88. A reviewer approves release through the secure banking portal. Before release, a refreshed control check shows that U17's relevant representation right has been revoked. The pack exists and its content may be correct, but the release must follow the bank's denial and escalation process. A successful generation job does not preserve an expired entitlement.

If the document is released successfully but the servicing-case update times out, the system should show two facts: document availability confirmed, case recording unresolved. It should reconcile the case before retrying a write or regenerating the document. Otherwise the operator may send a second pack merely to make the case screen appear complete.

The acceptance test should reproduce all three branches: an account outside scope, authority changing between preparation and release, and a partial downstream completion. These are more informative than demonstrating that the model can correctly translate the original Arabic request.

Keep a controlled read path into banking data

Prefer narrowly defined servicing functions over broad database access. A function that retrieves an approved statement reference for a specific authorised account is easier to govern than an agent with general query access to customer tables. If analytical access is genuinely required, establish its separate role, approved purpose and output restrictions. A read-only credential can still expose sensitive information at scale.

Test whether account scoping is enforced by the authoritative service or merely applied as a filter in the AI application. The latter can fail when another code path, cache or background job omits the filter. Review caching and attachment storage for the same customer and entity boundaries. Search results, error messages and document filenames can reveal information even when the document body is hidden.

Choose a practical security architecture that identifies each trust boundary and service identity. Keep secrets out of model context and customer-visible errors. An operational trace should let the bank investigate the account selection and delivery outcome without exposing credentials or creating an unnecessary second store of transaction data.

Apply the bank's regulatory and outsourcing assessment

SAMA's in-force banking outsourcing provisions require assessment of material outsourcing, including business justification, risk and provider selection. Whether a proposed AI integration constitutes outsourcing, and which requirements apply, needs the bank's compliance and risk assessment. Do not label every software connection material outsourcing or assume that a supplier's location settles the question.

Describe the actual service: who operates it, which bank information they can access, where processing and support occur, what subcontractors do and how the bank can exit. Distinguish an implementation supplier who hands over code from an ongoing managed service, while checking the real access and continuing responsibilities in both cases. Contract terminology alone does not describe the operational arrangement.

The data residency guide provides a way to inventory locations across processing, telemetry, backups and support. Regulatory conclusions should remain tied to the bank's entity, activity and data flows. Record the responsible approval and any deployment restrictions in the delivery scope so that a technical team does not discover them only at release.

Design evidence that operations can use

Log the servicing reference, evaluated account scope, relevant policy or entitlement result, approved document reference, release attempt and confirmed destination state. Record enough version information to explain a later dispute. Avoid copying complete statements into every system log. Where a source record may change, agree what reference or protected snapshot is needed to reconstruct the decision.

An exception queue should distinguish permission denial, unavailable entitlement service, statement-generation failure, uncertain delivery and failed case recording. Each has a different owner and remedy. “AI error” is not a useful operational category. A denial may be a correct control outcome; it should not automatically trigger a retry that uses broader credentials.

Use audit logging to specify the evidence trail and integration monitoring to decide which unresolved conditions need intervention. The bank should be able to inspect the chain without depending on the supplier's private dashboard or a developer's personal knowledge.

Accept the integration as a bank-operated service

Before release, test revocation, partial account authority, a changed recipient, a document regenerated after approval, a source-service outage and an unauthorised request embedded in a document. Include Arabic and English period expressions and entity names, but retain explicit account identifiers and date confirmation. Measure whether the correct state and next action are shown to the customer and operator.

Agree how to stop new document releases, preserve work already completed and recover pending requests. A rollback of application code cannot unsend a document or erase a customer's legitimate access history. Recovery procedures must address those business effects separately from deployment restoration.

Handover should include interface ownership, bank-controlled configuration, credential rotation, reconciliation instructions, evidence retention and the process for approving subsequent model or prompt changes. The release decision belongs to the bank's designated owners. Supplier completion and bank acceptance should refer to the same demonstrated scope.

Trusted Data's Saudi banking operations AI guide offers related operational context. To scope an integration, bring an appropriately masked servicing request, the entitlement model and the relevant application documentation. Discuss a banking AI integration project with a defined account, action and evidence boundary.