How AI is changing our finance operating model

AI has given us a reason to rethink how our Finance team is organised.

Not everyone on a Finance team needs to be a builder.

As soon as GenAI started becoming useful in our day-to-day work, we put the tools in the hands of the people closest to the work and watched to see what they could do with them. Teams across Finance experimented with vibe-coding simple tools, finding ways to remove friction from processes they knew firsthand. It was a great way to uncover opportunities to build and created a lot of energy around the potential of AI within the Finance function.

But we quickly discovered the limitations of scaling these solutions into productionised workflows that the entire team could use.

Our realisation as a team was that we needed an operating model that scales: which tasks are done centrally, which are distributed, and who does the building. This article sets out our answer so far.

The people closest to the work see the best opportunities

When I joined Airwallex, I was blown away by the enthusiasm of my team to start building with AI. Our model of building was based on citizen development, on the understanding that the people closest to the domain were best equipped to identify where AI could eliminate friction. While they had no engineering background, they had the technical acumen to experiment with vibe-coding tools to build solutions.

Across Finance, we’ve built dozens of tools this way.

Manual journal entries were an obvious place to begin because they're a huge drag on the team's time. Rather than waiting for Oracle to support Mac, a member of our Controllership team built a GL posting tool that let Mac users post journal entries directly into Oracle. Because he understood the finance workflow, he further reduced friction across the process, enabling quick entries, batch uploads, and more. In another instance, a senior financial controller self-taught coding and cut a manual payroll consolidation process from two days to ten minutes.

However, distributed experimentation has a natural limitation. Many of the projects started only reached about 70% completion. Each project was an independent endeavour, and while the team could build promising prototypes, they often ran into barriers and struggled to turn a prototype into a live, usable solution.

As more people started building, different teams sometimes solved similar problems in different ways, and the knowledge stayed with whoever built each tool. Without a shared roadmap, we had a great deal of activity and fewer coherent sets of outcomes or tools designed to be reused across Finance.

This led us to a different approach. We want more of these projects finished while maintaining the enthusiasm that started them. Citizen developers still build within their teams, and a central framework now sets how they scope, test, and ship.

We’re moving towards full automation

Automation runs along a spectrum:

1. Dashboards connect and visualise data that used to live across multiple systems.

2. Applications work like a co-pilot, though a person still uploads the data and copies the output somewhere else.

3. Triggered workflows start on their own, either on a schedule or in response to a business event.

4. End-to-end automation connects everything through APIs, and the only human step is an approval gate.

Most of our work sits in the first two stages. The returns arrive further along, where a process no longer needs a person to start it, feed it, and carry its output into the next system by hand. End-to-end automation is where we’re aiming to push into, supported by a new structure for how we develop within the team.

Getting there is harder than it sounds. Once a human is no longer in the loop, someone has to think through every edge case, and that is closer to a product manager's mindset than a finance professional's.

We needed a finance engineer

One of the first decisions I made as CFO was to hire a finance engineer who reports directly to me, someone responsible for our AI transformation within the function. This role is still rare in Finance, though I expect it to become a standard part of a finance team.

I wanted someone to drive best practice across everyone who builds in Finance and Corporate Development, with a standardised approach to scoping, testing, and defining what production readiness really looks like. Turning a personal workaround into a process that multiple people across all of our regions can rely on is a product skill.

Our finance engineer’s first project was to roll out our baseline mapping exercise and evaluate the insights it gleaned. These insights made it clearer where each function should focus its AI investments. They then worked with the leads of each function to scope and prioritise their builds, wrote the Skills (repeatable AI workflows) that capture how we want things done, and set the standard for what is ready to go live.

How we build now

The model that finds the opportunities is not the model that turns them into something the function can depend on, so every build now follows the same four steps:

1. Scope it rigorously, because getting this step right saves weeks later.

2. Build the MVP inside three to four weeks, with a check-in twice a week. If the deadline moves out of reach, we cut scope and keep the date.

3. Test it for two to three weeks with three or four testers from other regions, warned in advance that proper feedback is expected of them.

4. Ship it, lock it, publish the link in one team-wide sheet, and push adoption across our global teams.

Not every problem needs a custom software application. When one does, we build it properly. Increasingly, we find that many processes can be automated as agent Skills without the need to build complex custom software. Most importantly, we keep these Skills and our agents in central repositories that everyone on the Finance team can access and hopefully learn from.

The building itself stays with the domain experts, because they are still the source of our best ideas. What the structure gives them is SOPs, templates, and shared tools, so they can spend their time on the problem and far less on figuring out how to build.

The skill sets we're growing

Most of the change comes from our team building new skill sets. The most effective people here are domain experts who have learned how agent-powered software engineering works. Once our finance team members know how to build with agents, they can turn that knowledge into something repeatable and scalable, and teach it to everyone else across the function.

Where we have hired, it's been deliberate. In Tax, we brought in an experienced tax professional to automate tax compliance end-to-end, and we expect to save approximately US$1 million a year by bringing more of the filing process in-house.

AI transformation is mostly a leadership challenge. I expect everyone in my leadership team to personally drive the transformation of their own department. They should lead by example, whether that means championing a builder's mindset or thinking AI-first. That means taking a step back to question whether today's processes make sense and thinking beyond automating individual tasks.

Efficiencies only appear once a tool is used across the whole function, by people who trust it enough to stop keeping a spreadsheet alongside it. That is the standard we hold every build to.