Buying AI for an Australian bank: what to ask before you sign
An AI demonstration can show that a task is possible. It cannot, by itself, show that the proposed service is ready for a bank. Before customers or staff depend on it, you need answers about information, mistakes, interruptions and ongoing support. This guide turns those questions into a practical evidence pack for a pilot. It explains the relevant APRA standards once, then focuses on what to ask a supplier to show you.
What to take away
- Start with one business process and clear limits on what the system can do.
- Ask for demonstrations and test records, alongside policies and supplier credentials.
- Agree how to stop, change or leave the service before it becomes essential.
1. Describe the job before choosing the technology
Write the proposed job in one sentence. “Draft a response from approved complaint records for a staff member to review” is a usable starting point. “Transform customer service with AI” leaves too many decisions undefined. Name the person who will use the output, the information they need and the action that follows.
Then list the limits. Can the system send a message, change an account, recommend a decision or only prepare a draft? For the complaint example, an initial pilot could prevent sending and account changes. The reviewer remains responsible for checking the response. A narrow first scope makes errors easier to observe and the value easier to measure.
2. Know which requirements apply to the arrangement
APRA’s CPS 230 covers operational risk, including continuity and supplier arrangements. Its current version commenced on 1 July 2026. For material arrangements, it requires due diligence before entering or materially changing the arrangement. Materiality depends on supporting a critical operation or creating material operational risk, with specified service categories also considered. The current standard includes limited exemptions from particular requirements.
CPS 234 covers information security. When another party manages a bank’s information assets, the bank must assess its security capability and evaluate its control design. These are requirements for the relevant regulated entity; they do not create a general “APRA-certified AI supplier” badge. Ask your risk and legal teams to determine the applicable requirements. The workflow below is our practical recommendation, not a complete compliance checklist.
3. Follow one customer record through the whole service
Ask the supplier to walk through a made-up complaint from upload to deletion. Where does the document go? Which parts reach a model? What appears in application logs? Who can access support tools? Does the answer change when a staff member attaches a file rather than pasting text?
Turn the walkthrough into a simple diagram with named organisations and locations. Record what is stored, for how long, who can retrieve it and how deletion is checked. Include error reports and backups in the questions. An answer about the main database alone leaves other copies unexplained. Resolve gaps before introducing real customer information, using the bank’s approved process for access and data handling.
4. Test the work your team actually needs done
ASIC’s 2024 review of 23 financial-services and credit licensees described stronger supplier oversight that combined supplier validation evidence with internal validation, model-change notification and ongoing monitoring. These were examples of better practice, rather than a newly prescribed approval form.
For the complaint assistant, prepare cases with incomplete records, contradictory details and a policy that has changed. Include ordinary cases as well as difficult ones. Agree what a reviewer must check: supported facts, relevant policy, appropriate wording and correct escalation. Keep some cases unseen until the final assessment. Report which kinds of case fail; a single average can hide the exact work your team cannot safely delegate.
5. Make human review a real step
“A person checks it” needs a practical explanation. Can that person see the information behind an answer? Do they have enough time to check it? Can they reject it without fighting the interface? Does a confident-looking draft make an unsupported statement harder to notice?
Run a session with the people who would do the work. Give them deliberately flawed drafts and watch whether they identify the problems. Measure the complete task, including checking and correction, rather than only generation time. Record who handles an uncertain case and where it goes next. The useful outcome is a process the team can operate, with a clear route for cases the system cannot handle.
6. Rehearse interruption, change and exit
Ask for three short demonstrations. First, make the AI service unavailable: can staff still find the underlying records and continue the agreed process? Second, change the model or instructions: can the team compare results, approve the change and return to the previous version? Third, end the trial: can you obtain the information and records you need in a usable format?
Treat a successful demonstration as evidence for the conditions tested, not a promise that every failure is covered. Keep the date, environment, result and unresolved problems. Assign an owner to each problem. This makes the next discussion specific: what must be fixed before the service takes on more responsibility?
7. Finish with a decision someone can explain
Supplier credentials can support the assessment, but inspect what they cover. APRA’s CPG 234 guidance points to the scope, depth and independence of supplied assurance. A report about one platform or period may leave the proposed application or a later change outside its coverage.
Bring the findings together in a short decision brief: the business problem, proposed limits, observed benefits, failed tests, unresolved questions and owner of each next action. Choose whether to proceed within a limited scope, revise the pilot or stop. Keep the acceptance conditions measurable. “All approved test cases retain a traceable source” is easier to review than “the assistant seems trustworthy”.
Bring these seven items to the supplier review
- One defined job, named users and explicit limits on system actions.
- An information-flow diagram covering storage, logs and support access.
- The bank’s assessment of applicable requirements and arrangement materiality.
- Representative test cases, agreed acceptance rules and recorded failures.
- A demonstrated review process with clear responsibility for uncertain cases.
- Evidence from interruption, change, rollback and export exercises.
- A short decision brief with open issues, owners and approval conditions.
Sources and further reading
Official sources support the requirements described here. Our suggested workflows and illustrative examples are practical guidance, not an assurance of compliance or a claim about client results.
- CPS 230 Operational Risk ManagementAPRA
Current standard commenced 1 July 2026. Checked 25 September 2026.
- CPS 234 Information SecurityAPRA
Information assets managed by other parties and control testing. Checked 25 September 2026.
- REP 798: Beware the gap — governance arrangements in the face of AI innovationASIC
Published 29 October 2024; third-party oversight examples on pages 31–32. Checked 25 September 2026.
- CPG 234 Information SecurityAPRA
Practice guidance, distinct from enforceable standard requirements. Checked 25 September 2026.