Skip to main content

Control objectives - how AIS programs map to bank expectations

Banks typically map vendors to control objectives (not line-by-line controls in this portal). Below is language risk committees recognize, tied to what AIS deployments are designed to support in product and gateway documentation. Gaps or limits are called out explicitly.

Access control (logical)​

Objective: only authorized people and systems can use AIS-backed functions and data.

What AIS programs commonly include (subject to how you deploy):

  • Human access: sign-in, optional MFA, and role-based permissions for Decision PRO and related admin surfaces-see Security & access.
  • Machine access: authenticated REST calls to the Pro Gateway (for example JWT bearer tokens and, when enabled, API keys)-see Authentication concepts.

What your bank still owns: joiner/mover/leaver processes, periodic access reviews, and break-glass accounts-implemented in your IdP and processes.

:::note No absolute guarantee of “no misuse”

Access controls reduce risk; they do not remove the need for monitoring, culture, and supervisory oversight.

:::

Segregation of duties (high level)​

Objective: sensitive actions require independent review or dual control where your policy demands it.

How product design can help: roles can separate data entry from approval workflows for lending decisions-exact workflows and role names depend on your configuration and contract.

Bank responsibility: define which pairs of duties must never sit on a single ID without compensating controls; AIS helps enforce what you configure-it does not replace your SoD policy statement.

Logging, traceability, and audit trails​

Objective: support investigations, customer disputes, and audit sampling with trustworthy records.

Themes reflected in AIS integration documentation:

  • Gateway and APIs: responses may include identifiers such as X-Correlation-ID (or equivalent) so bank IT can tie a browser or API session to gateway logs when investigating incidents-confirm header names and retention in your environment.
  • Administrative domains: Pro Gateway documentation describes admin areas that can include audit-oriented capabilities (for example audit log surfaces in the API surface)-which events are recorded, retention, and export format are deployment- and contract-specific.

Decision PRO may record user actions relevant to credit decisions (who viewed or changed what)-field-level detail belongs in your functional spec or AIS annex, not in this overview.

:::caution Retention is not universal

Log and audit retention periods, immutability, and WORM requirements must match your legal and supervisory expectations and be written into agreements where needed.

:::

Change management (models, policy, software)​

Objective: production changes are authorized, tested, and traceable.

Typical split (confirm in contract):

  • AIS operates platform releases, patches, and model deployment pipelines as scoped in the agreement.
  • Your bank approves credit policy and data use changes that affect customer outcomes, often through credit committee and IT change advisory boards.

Joint practice: use sandbox environments (see Environments) for regression before production promotion-whether a permanent sandbox exists and how promotions are gated are contractual.

Next: Evidence & diligence · Overview