When the bank must act vs transparent platform updates
Use this page in joint change forums so everyone agrees who moves first. Wording here is generic; your contract and integration annex win on any conflict.
Quick reference
| Type | Examples (illustrative) | Typical bank action |
|---|---|---|
| Transparent platform | Security patches with no API contract change, performance tuning, bug fix invisible to users | None beyond awareness; optional regression smoke if you always test |
| Coordinate & communicate | New Decision PRO screen, renamed status, default filter change | Training, FAQ, branch bulletin; may need change advisory record |
| Bank must act | Certificate rotation on your API client, IP allow list update, credential rotation, schema change on your payload | Your IT executes in an agreed window; AIS may pause traffic until done |
| Joint cutover | New mandatory field on create‑application API | Dev + ops in both orgs; sandbox proof first |
“No bank action” does not mean “no bank awareness”
Even transparent updates can coincide with higher error rates during rollout. Good practice:
- Keep a lightweight weekly read of AIS ops email (or equivalent).
- After major releases, run your golden path test in sandbox if available.
API and integration readers
If a change touches HTTP contracts, bank IT should follow Integrations & connectivity and the OpenAPI appendix. Breaking changes should be versioned or flagged per your agreement-if unsure, open a ticket before go‑live weekend work.
Back: Overview