Trend analysis

AI in Accounting and Finance: A Control and Governance Framework

AI features arrive through updates rather than decisions. Responsibility does not transfer to the tool, and the controls that hold are procedural, not technical.

AI features are now embedded in accounting software, spreadsheets, email and document processing, usually arriving through an update rather than a decision to adopt them. The governance question is therefore not whether to permit AI in a finance function. It is which decisions the technology may influence, what evidence remains behind those decisions, and which controls still hold when an output — or an instruction — is entirely plausible and entirely wrong.

The accountability position does not change

Start here, because it determines everything else. Where technology is used to prepare or analyse financial information, responsibility for that information remains with the people and the organisation producing it. An output is an input to a judgement, not the judgement.

For a Malaysian company this is concrete: directors remain responsible for the financial statements, and a preparer remains responsible for the work. "The system generated it" is not a basis for a position taken in a return or a set of accounts, and it is not an answer to an auditor, a lender or a regulator.

The same principle is written into Malaysia's data protection regime. Under the Personal Data Protection Act 2010 as amended by the Personal Data Protection (Amendment) Act 2024, the appointment of a data protection officer does not discharge the data controller or the data processor from its duties and functions under the Act. Responsibility is allocated to the organisation and stays there. Naming a person — or adopting a tool — does not move it.

Classify uses by consequence

Not all use carries the same risk, and treating it uniformly leads either to a blanket prohibition that staff quietly work around, or to no control at all. A workable distinction:

  • Low consequence — drafting internal text, summarising a document someone will read anyway, suggesting a formula. Errors are visible and cheap.
  • Material consequence — transaction coding, reconciliation matching, anomaly detection, extracting figures from documents. Errors propagate into the records and may not be visible downstream.
  • High consequence — anything influencing a judgement, estimate, disclosure or tax position. These require a documented human basis regardless of what the tool produced.

The control effort belongs in the second and third categories. A policy that spends its length restricting the first, while saying nothing about who may paste a trial balance into an external service, has been written backwards.

Confidentiality is the immediate exposure

The most common failure is not a wrong answer. It is data leaving the organisation, in a way nobody decided and nobody recorded.

Establish which tools may receive client financial information, personal data or commercially sensitive material, and on what terms that data is processed, retained and used. A tool that processes data outside Malaysia, or retains it, presents a different decision from one that does not — and it is the organisation's decision, not that of whoever is under time pressure.

The regime itself has moved. The Amendment Act received Royal Assent on 9 October 2024 and was gazetted on 17 October 2024, its provisions commencing on dates appointed by the Minister rather than all at once. The term "data user" was replaced throughout with "data controller", and duties now expressly reach data processors as well as controllers, so an organisation processing data on another's behalf carries obligations in its own right. Current requirements, forms and timeframes should be taken from the Commissioner's own published guidelines rather than from summaries.

Two points hold regardless of the detail. Personal data obligations do not lapse because a third-party tool did the processing. And where information is held under a duty of confidentiality — as it is throughout a finance function, and under the MIA By-Laws for a professional accountant — entering it into a general-purpose service may breach that duty whatever the quality of the output. That is a decision to take deliberately in advance, not one left to individual staff at the point of use.

Verification must be proportionate to consequence

Output is confident in tone whether or not it is correct, which is precisely what makes unverified use hazardous in a finance context. Fluency is not accuracy, and a well-formatted answer is not a checked one.

For anything material, the person using the tool needs to verify the output against source records rather than review it for plausibility. A reconciliation matched by a tool still has to reconcile. A figure extracted from a document still has to agree to that document. A summary of a contract is not evidence of what the contract says.

Where a tool contributed to a material judgement, record what it produced, what was verified and against what, and who accepted the result. That record is what allows the position to be explained afterwards, and it separates a supported judgement from an unsupported one.

Plausibility is not verification, and instructions are no exception

The same failure mode appears on the way in, and it is where finance functions lose money.

Most losses in Malaysian finance teams do not begin with a technical compromise. They begin with a legitimate payment sent to a fraudulent destination by a real employee following what appeared to be a real instruction: correct letterhead, plausible reason, often a genuinely compromised email account. Nothing in the message reveals it. Only independent verification does. Tools that produce convincing text, and increasingly convincing voice, make "does this look right?" a weaker test than it already was.

Two controls carry most of the weight, and neither depends on anyone spotting anything:

  • Verify every change of bank details out of band. Any change to a supplier's or an employee's account details, however it arrives, is verified by contacting a known person on a number already held on file — never a number, address or link contained in the request itself. The verification is recorded.
  • Do not let authority follow urgency. Payments above a defined threshold require a second authoriser, with no exception for urgency, confidentiality or seniority. An instruction that discourages verification is itself the warning sign. Staff need explicit, advance permission to apply the rule to a director, or they will not apply it.

Both work precisely because they do not ask anyone to judge whether something looks genuine.

Access and attribution make the rules enforceable

A policy about which tools may receive which data is unenforceable if nobody can establish who did what.

Access accumulates quietly. People change roles and keep old permissions, leavers retain access for weeks, and shared logins make attribution impossible. Review who can approve payments, amend master data, reach banking platforms and enable features within accounting software — because embedded functionality is often switched on per user, which means the adoption decision has effectively been delegated to whoever clicks it.

Remove access on the day someone leaves rather than at the next review. Use individual accounts rather than shared ones. Attribution matters when something goes wrong, and it is the only way a control can be shown to have operated.

Decide the incident response before you need it

Where a fraudulent payment is made, the first hours matter. Agree in advance who is contacted first at the bank, who has authority to instruct a recall, who informs management, and how evidence is preserved rather than deleted while trying to put things right.

Where personal data may be affected, there is now a statutory step rather than a discretionary one. The Amendment Act inserted a data breach notification duty: where a data controller has reason to believe that a personal data breach has occurred, it shall as soon as practicable notify the Commissioner in the manner and form determined by the Commissioner; and where the breach causes or is likely to cause significant harm to the data subject, the data subject shall be notified without unnecessary delay. The applicable timeframes and forms sit in the Commissioner's guidelines and should be confirmed there. The point for planning is that the obligation is triggered by reasonable belief rather than by confirmed loss, so the assessment cannot wait until an investigation is complete.

One continuity check belongs alongside this. A backup that has never been restored is an assumption, not a control. Confirm that at least one copy is unreachable from the systems it protects, and that a restoration has been performed and timed. The question is not whether backups exist but how quickly invoicing and payments could resume, and who would do it.

What to put in place, and what not to buy

Very little of this requires expenditure, and it is worth saying so plainly.

A small finance team does not need a purchased governance framework, an externally drafted policy or a software product to address most of the exposure here. Call-back verification, a second authoriser, individual logins, prompt removal of leaver access and a written rule about which information may be entered into which tools cost management attention rather than fees. A one-page rule the team has agreed and understood is generally observed more reliably than a long document it has not read.

Outside input is more likely to be warranted where personal data is processed at scale or transferred outside Malaysia; where a data protection officer's appointment and role must be worked through; where an incident has occurred and the notification position must be established quickly; where a tool is proposed for a material-consequence use and its retention terms need assessment; and where the finance function's systems are being replaced rather than adjusted. Otherwise the internal route is usually cheaper and more effective.

A workable sequence:

  1. Identify which tools are already in use, including features embedded in existing software and enabled per user.
  2. Define which categories of information may be entered into which tools, and record the basis for that decision.
  3. Classify uses by consequence and set verification expectations for each.
  4. Require a documented human basis for any judgement, estimate or disclosure.
  5. Verify all bank detail changes by call-back to a number already held on file, and require dual authorisation above a defined threshold.
  6. Review access rights, use individual accounts, and remove leaver access immediately.
  7. Confirm the processing, retention and location terms of any tool handling confidential or personal data.
  8. Agree incident contacts, evidence-preservation steps and the personal data notification route in advance, and test a restoration from backup.
  9. Assign ownership of the policy and review it as tools change, which they do without asking.

General-information limitation

This article is general information, not technology, legal or data-protection advice for a particular organisation, and it does not determine the appropriateness of any tool, the adequacy of any control environment, or any obligation under the PDPA 2010 or professional requirements. Current data protection requirements, guidelines and timeframes should be confirmed against the Personal Data Protection Department's own published material. Obtain fact-specific advice where the matter is material.

To discuss your circumstances, contact Saifudin & Co.

Related service

START WITH SCOPE

Define the requirement before the work begins.

Tell us the entity, reporting period, applicable requirement and intended use. We will confirm fit, scope and the next evidence needed.

Discuss the engagement