How to let an AI agent update customer records in your core banking system

Grant write access field by field, not record by record. Preferences and verified addresses can be depth 3 work. Phone and email changes are takeover routes, so they are held or confirmed through the old contact. Names, dates of birth, risk ratings and account status stay with people. Every write is filed with old value, new value and evidence.

What does updating a customer record involve, and who owns it?

The core banking system holds the customer record that every other system trusts: name, identity details, addresses, contact points, tax residency, risk markers and account status. A change there flows into statements, payment checks, screening and regulatory reports. A wrong change is copied everywhere.

Customer operations usually owns routine maintenance. Financial crime owns risk markers. Each field also has an owner in data governance, even if nobody has written that down. Before an agent touches the record, write it down. It is very different from updating records in a CRM, where a wrong field affects a sales call rather than a payment.

Which fields get which grant?

The steps:

1. Agent, depth 1: reads the request and the record. It identifies which fields would change and checks the change history for recent edits.
2. Agent, depth 1: checks the evidence. A utility bill for an address, a deed poll or marriage certificate for a name, a self-certification for tax residency.
3. Agent, depth 3: writes low-risk fields. Preferences and evidenced addresses on accounts with no fraud or vulnerability flags.
4. Agent, depth 2: prepares contact changes. It sends a confirmation to the existing phone or email. If the customer confirms there, the change can proceed at depth 3; if not, it is held.
5. Agent, depth 2: prepares identity changes. Name and date of birth changes are drafted with documents for a person to approve.
6. Person: approves held changes. A named person reviews, approves or rejects.
7. Agent, depth 3: notifies the customer through the old and new contact points that a change was made.

Why are contact changes treated as high risk?

Changing the phone number or email on a record is often the first step in an account takeover. Once the fraudster controls the contact point, one-time passcodes and alerts go to them. An agent that changes contact details on request, without independent confirmation, becomes the easiest route in.

Two controls follow. Confirmation goes to the old contact point, never the new one. And after any contact change, higher-risk actions such as new payees or limit increases are held for a cooling-off period your fraud team sets. The agent does not decide that period; it enforces it, because it sits in the customer's own limits in the minimum chain.

How do you give access and take it away?

Use a dedicated core banking user for the agent, with a role that can write only the granted fields. Giving an agent safe access to your core banking system covers the connection pattern, including why the agent should call a narrow service rather than the core directly.

Revocation works in layers. Remove a field from the grant, and writes to it are refused from the next request. Disable the user, and the agent can no longer reach the core at all. Let the certificate lapse, after 90 days or on a failed run, and the agent drops to depth 1. Held drafts remain for people to finish.

What is recorded?

Each write is filed with the field, the old value, the new value, the evidence reference and its provenance class, the five bounds checked, the bound that decided, and the verdict. The core banking system keeps its own change log too. The two should reconcile: every agent change in the core should have a matching verdict, and any core change by the agent's user without one is an incident.

Refused attempts matter as much as allowed ones. If the agent is repeatedly refused on a field, either the brief invites it or someone is trying to talk it into a change.

What should you measure?

• Changes completed at depth 3 against held. Shows where the real workload sits.
• Held changes rejected, by field. High rejection on addresses suggests weak evidence checks.
• Contact changes followed by fraud claims. The key safety measure.
• Mismatches between the core change log and filed verdicts. Should be none.
• Downstream breaks. Statements returned, screening hits caused by bad name edits.

Where does it usually go wrong?

One role for the whole record. The integration user can write every field, and limits live only in the brief. Fix it in the role.

Formatting as editing. The agent "tidies" a name into title case or removes a hyphen, and the screening match changes. Treat any change to an identity field as an identity change.

Bulk updates. A request to update many records at once, such as a branch address change, needs its own capability and its own certificate, not a loop over the single-record grant.

Credit data mixed in. Records in the core are not the customer's credit file, and whether an agent can update a customer's credit file is a separate question with its own rules.

Banking-wide limits are in AI agents in banking.