Releases and how banks learn about changes
Banks need predictable, readable change information-not a dump of every internal commit. AIS programs usually separate:
- Partner release bulletin - what business and operations users should know (behavior, training, cutover dates).
- Technical release notes - for bank IT (API quirks, deprecations, header changes)-often under NDA or in a technical pack.
- Engineering changelog - line‑item history for AIS developers (high volume, jargon heavy).
This portal focuses on (1) at a process level; it does not mirror AIS engineering history.
Typical notification channels (confirm yours)
| Channel | Best for | Notes |
|---|---|---|
| Email digest from AIS CSM / support | Ops leads, IT integration | Attach impact and action flags |
| Quarterly business review | Roadmap, major capabilities | Good for training planning |
| Partner workshop | Large UI or policy workflow changes | Recordings under your records policy |
| Partner documentation portal | Curated product and ops pages | Prefer this site over engineering changelogs |
| Status / maintenance page | Planned work + live incidents | Per deployment |
:::caution Monorepo changelog.md is engineering‑first
The AIS repository maintains a developer‑oriented changelog.md at the repo root for internal continuity. Do not treat it as an approved bank communication. Bank IT may subscribe to engineering feeds only if your security policy allows and AIS grants access-still use the partner bulletin for ops messaging.
:::
What a good partner bulletin contains
- Release ID or date and environments affected (sandbox first, then production-if that is your pattern).
- User‑visible changes (screens, labels, default sorting, new fields).
- Known issues and workarounds.
- Training hint: “watch 3‑minute clip” or “attend office hours.”
How you can verify
- Ask AIS for a sample bulletin from a past release (redacted if needed).
- Agree minimum lead time before production promotion for material changes.