Data categories & handling (high level)
Banks must know what data crosses into AIS, why, and how long it is retained. Exact fields and retention are contractual; this page uses placeholders your privacy and security teams can map to your standards.
Placeholder categories (examples)
| Category | Examples (illustrative only) | Typical sensitivity |
|---|---|---|
| A - Application facts | Income band, employment type, loan purpose category | Often personal / regulated |
| B - Credit history surrogates | Bureau codes or scores as allowed by contract | Highly sensitive |
| C - Product context | Product code, branch, channel | Often internal business |
| D - Model outputs | Decision category, reason codes, confidence summaries | Business confidential |
:::note What this means for you
Treat every field as sensitive until your DPIA / privacy review says otherwise. AIS should only receive minimum necessary data for the decision you intend.
:::
Logging and monitoring (concepts only)
- Audit trails capture who did what in the product, aligned to bank users and AIS operators as contracted.
- Technical logs help AIS run the platform; they are not the same as your credit file. What appears in each is deployment-specific.
What AIS does not publish here
- Internal log field dictionaries, database schemas, or encryption key handling procedures-those belong in a technical pack for bank IT under NDA.
What your bank can do
- Run a data minimization workshop with AIS before go-live.
- Align on retention and deletion timelines with your DPO.
Exact categories for your bank - confirm with your AIS account team.
Next: Bank and AIS roles · Boundaries