By Macer Skeels, CTO and Co-Founder, FinanceKey

At FinanceKey, we’ve built our engineering philosophy around a simple principle: do whatever it takes to get the job done securely, efficiently, and in a way that delivers lasting value for clients. 

That’s what we mean by hyperautomation. The term was popularised a few years ago by Gartner, the technology research firm known for spotting emerging trends in enterprise IT. 

In their words, “Hyperautomation is a strategy to increase the automation of business and IT processes by orchestrating the use of multiple technologies, tools and platforms”. 

For us, it’s less about labels and more about mindset. Hyperautomation isn’t a methodology, it’s the recognition that no single technology solves every problem. The best way to build is to stay flexible, tool-agnostic, and relentlessly focused on outcomes. 

Systems have always talked to each other

APIs aren’t new in the sense that systems have been communicating in automated ways for decades. One of the earliest local forms of API commonly used in the 1990s was the “mail merge” functionality whereby two applications communicated with each other, exchanged data and triggered actions automatically.  

Over time, more sophisticated and distributed integrations have evolved: 

• DDE, COM, and OLE for application-to-application automation on desktop PCs 
• File-based integration via CSV, fixed-width files, and FTP 
• EDI (Electronic Data Interchange) for structured business document exchange 
• SOAP and XML for formal web service contracts 
• REST and JSON for scalable, web-native APIs 

Each reflects a point in time — but all serve the same goal: letting systems talk to each other to reduce manual work. And as protocols matured, so did their security — from simple IP restrictions and API keys to OAuth, token scopes, and fine-grained access control. 

Why build API-first (but not API-only)

At FinanceKey, we design everything API-first. That means we build our systems to ensure they can be consumed directly by other machines before we even think about the user interface. UI is then layered on top of those APIs, resulting in a platform that is not only user-friendly, but also automation ready from day one. 

This approach of making sure the system is accessible, extensible and programmable from the outset provides flexibility to our clients: if they do not wish to use our UI, they are able to seamlessly connect via other platforms. 

Hyperautomation in practice

Our approach to integrating with NetSuite –  a mature system with five different ways to bring in bank statements – perfectly illustrates how FinanceKey has put hyperautomation into practice.  

Our goal was to find a solution that would work for all NetSuite customers, regardless of the modules they had licensed. 

After careful analysis, SOAP was identified as the strongest solution as it provided the best automation experience without incurring additional costs. 

Whilst REST APIs are easier to maintain, more flexible and well-aligned with how most modern systems operate, FinanceKey will always opt for the best technology to get the job done (e.g. a secure file transfer, a SOAP call, or even an API that wraps a file). 

That’s hyperautomation in a nutshell: customer-first, then technology. Adapt to what’s available, always with automation and security in mind. 

Automation as collaboration 

One of my earliest automation wins occurred during my time at Nokia, when we integrated the first banking APIs into our treasury systems. For users, the results were powerful: real-time transaction data and payment confirmations at their fingertips. 

But the truth is, we didn’t build that functionality ourselves, the bank did.  We consumed it and realised all the benefit from the bank’s engineering efforts. 

That’s the beauty of working with APIs. You can combine great tools from different teams and get to a solution faster, more efficiently and creatively.  

What it means for treasury IT teams

If you’re working in treasury IT, your concerns are straightforward: 

• Can we automate this process? 
• Will it integrate with our stack? 
• Can it be done without compromising security? 

You’re not debating whether REST is better than SOAP. You want something that works, fits into existing systems, and delivers reliable results. 

That’s exactly where hyperautomation shines. It removes the constraints and lets us integrate faster.   

Final thoughts

Hyperautomation is how we build at FinanceKey. 

In the end, the goal isn’t to follow a trend. The goal is to get the job done securely, reliably and in a way that makes life easier for treasury teams. 

That’s what matters. That’s what works.