Why a named approver beats hoping the AI will handle it.

Every system that lets something change money or customer facing facts ends up answering two questions. Who decides, and how much scrutiny does each decision get? Banks, payment processors, IT departments and regulators have worked on both for a long time, and their answers are written down. A merchant adding an AI assistant to a store can borrow them instead of inventing a policy.

This post collects those answers from public sources. It starts with the control for who signs, moves to the three way sorting of changes used in IT service management, shows how a payment platform and Shopify tier risk in practice, and ends with what the EU AI Act and the UK Information Commissioner say a person overseeing an automated system must be able to do.

Who signs: segregation of duties

The New Zealand Serious Fraud Office, which publishes counter fraud guidance for public bodies, defines segregation of duties as sharing tasks and permissions for a specific business process among multiple employees. Its examples are plain: vendors cannot both create records and process invoices, credit card approvers cannot also verify payments, and people who order assets cannot confirm delivery in the system.

The guidance lists what goes wrong without it: fraudulent payments, unauthorised data access, poor decision making, fake vendor creation and concealed employee misconduct. For smaller organisations it suggests testing the control in practice. Ask staff how the process works, confirm they understand why the separation exists, verify that the system enforces it, check that people cannot override it, analyse user permissions, and sample completed transactions.

The Scottish Public Finance Manual, which sets rules for Scottish public bodies, lists segregation and rotation of duties among a range of controls, alongside physical checks, reconciliations, supervisory checks and clear roles. It adds a principle that applies to any size of business: the degree of control within a system should be proportional to the risks involved, the consequences of failure and the resource costs.

Translate this to a store with an AI assistant. The assistant, or the colleague who asked it to act, is the maker of a change. The approver is someone else, and the approver's name is recorded. The rule you want to avoid is the one where the person who typed the request is also the person who clicks approve in the same minute. On a team of two, that means the owner approves what the other person asked for. In a team of one, the check that is left is a pause: a draft status, a next day review, a rule that edits to prices wait overnight.

The Scottish manual's proportionality principle matters here because approval has a cost. A merchant who sends every change, however small, through the same ceremony will start to click through. Control should rise with risk, which is where the next idea comes in.

Three kinds of change: the ITIL model

ITIL is the best known framework for running IT services, and its change enablement practice sorts changes into three types. A summary on the ITSM.tools site gives the working definitions. A standard change is pre approved, low risk and repeatable, and is usually automated or written up in a runbook. A normal change requires risk assessment and approval, handled according to urgency, complexity and impact. An emergency change is time sensitive, aimed at preventing a major incident, and is expedited, usually with a review after it is made.

The same page describes who authorises. Standard changes can be approved automatically or by delegated authorities without a central board. Normal changes go to the appropriate change authority for their level of risk. Emergency changes are assessed by the change authority given the critical nature of the situation. A change authority can be a delegated team, a peer review mechanism for standard changes, an automated approval process in a deployment pipeline, or business stakeholders for high risk changes.

The useful idea is that approval effort is not uniform. Routine work is approved once, as a class. Unusual work is approved one item at a time. Urgent work is allowed to move first and is checked after. The table below applies the three classes to a Shopify store. The examples are illustrations, not ITIL's.

The emergency class is a trap if it is not bounded. Its definition allows approval after the fact, which is why it should be rare, named and followed by a review. A store where every change is an emergency has no approval at all.

How a payment platform tiers risk

Stripe's Radar rules are a concrete example of risk bands in a live system. Rules take one of four actions: request 3D Secure authentication, allow, block or review. Stripe's documentation says all transactions are screened by default rules. By default it blocks payments at the highest risk level, and for payments suspected to have an elevated risk of fraud it requires review.

What Stripe advises about each action reads like a guide to approvals. Review rules do not stop a payment. Stripe still processes it, and adds it to a review queue so your team can look more closely. For block rules it is cautious: if you are not sure how to apply them, use a review rule first, check the false positives, and only then decide whether to block. For allow rules the warning is stronger. Allow rules override all other rules and the Stripe default rules, so use them minimally and add a condition that still blocks the highest risk level.

The rollout advice applies to any automatic permission you grant. Stripe lets you set the percentage of matching payments that a custom rule affects. It suggests starting small and raising it as you review how the rule performs. At 0 per cent the rule runs in shadow, reporting what would have happened without acting. The same document says only the account owner, administrators and developers can create rules, and that a rule activity log records when a rule was created, edited, enabled or disabled and by which user, for the past 180 days.

• 180 days

  how far back Stripe's rule activity log shows rule changes

  Stripe, fraud prevention rules, 2026

• 14 September 2019

  date UK strong customer authentication rules began to apply

  FCA, strong customer authentication, 2026

• 3

  risk levels in Shopify fraud analysis: low, medium and high

  Shopify Help Center, fraud analysis, 2026

Shopify's own tiers: fraud analysis

Shopify applies the same pattern to orders. Its fraud analysis assigns each order a low, medium or high risk of chargeback due to fraud. Medium and high risk orders are flagged on the Orders page with a warning symbol next to the order number. Low risk orders pass without that mark.

The merchant remains the decider. For a medium or high risk order Shopify offers three recommendations: you can fulfil it, confirm with the customer before fulfilling, or consider cancelling it. For a high risk order, it says you can attempt to verify the order, cancel it or refund it. The indicators behind the rating include whether the card passes Address Verification System checks, whether the customer gave the correct card verification code, whether the customer's location matches the payment method, whether there is unusual device or network activity, and whether the customer tried more than one card.

Shopify also tells merchants to review both the risk level and the recommended next step, and not to rely on individual indicators alone. That is a small version of a good approval screen: a band, a reason and a recommendation, all visible before you act, with the final call left to a person.

A rule that forces an extra check: strong customer authentication

UK payment rules go a step further and make the extra check mandatory in defined cases. The Financial Conduct Authority explains that since 14 September 2019, rules in the Payment Services Regulations 2017 have affected how banks and other payment providers check that a person asking to access an account or make a payment is allowed to. They are known as strong customer authentication. The FCA says it applies when a payer initiates an electronic payment, accesses a payment account online, or carries out any remote action that may imply a risk of payment fraud, unless an exemption applies.

The exemptions show the risk logic. Contactless point of sale payments can be exempt when specific conditions are met, and a reauthentication exemption means customers need not authenticate again when accessing account information through third party providers if they give explicit consent every 90 days. The FCA also expects firms to offer several different methods of authentication so that customers who cannot use a mobile phone are served.

Stripe's page ties this to its tools. It says Stripe triggers 3D Secure when necessary in line with regulations such as the strong customer authentication mandate of PSD2, and that disabling Radar does not stop that. If 3D Secure authenticates a payment, liability for fraud related disputes typically shifts from the seller to the issuer. A heavier check moves responsibility, which is also what a named approver does.

One more detail from Stripe's documentation is worth borrowing. It says you can test a rule against the last six months of payments before turning it on, so the person approving a rule sees what it would have done to real history. An approver who is shown the likely effect of a change, and not only its wording, is far better placed to say no.

What oversight requires of a person

A name on an approval is only useful if the person could have said no. The EU AI Act, in Article 14, describes what human oversight must allow for high risk AI systems. It applies to the systems the Act classes as high risk, and a store's product copy is not obviously among them, so read it as a description of what a capable overseer needs rather than a rule you must meet. The text says the people assigned to oversight must be enabled to properly understand the system's capacities and limitations and to monitor it for anomalies. They must remain aware of the possible tendency of automatically relying or over relying on the output. They must be able to correctly interpret the output, to decide not to use the system or to disregard, override or reverse the output, and to intervene in the operation through a stop button or similar procedure. The source gives application dates of 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems.

The warning about over reliance is the practical one for an approver who sees fifty small changes a day. The ICO makes a related point in the UK, in its guidance on automated decisions under the UK GDPR. Human involvement should come after the automated decision and relate to the actual outcome. If a person only supplies data to the system, the ICO says the person's involvement in the decision is not meaningful.

Put the two together and the approver's checklist is short. See the exact change. Have what is needed to understand it. Be able to refuse it. Be able to stop the run. If any of the four is missing, the name on the approval is decoration.

Where BYOM fits

Every change to a connected system is an Action, approved by a person on your team. Their name stays on the record. If you asked Kina for the change and your role lets you approve it, you can approve it yourself. Otherwise someone else on the team does. Each Action carries a risk band before you sign, so the weightiest changes stand out.