How API’s will revolutionize HCM & payroll
You’ve probably heard about Application Programming Interfaces or APIs. They are pieces of code that connect systems with each other to exchange data and have been around for a long time. So why am I writing about them today?
Going forward, HR and payroll technology might change in a way that could transform the entire business landscape for employers and employees alike. This is driven by a new generation of APIs that allow companies to collaborate, interact and transact with one another in ways they never have before. These 3rd party APIs can directly access HR or payroll data and offer eg personalized financial or benefits services to employees, using that data. In that way, a company can seamlessly offer external services to internal workers. But it comes with a trade-off. Let’s explore.
What is an API?
API’s take data from one source and make it available somewhere else. An example of how an API can be used is Google Maps. I am sure you have come across a company web page with a small Google map showing its location. Behind the scenes, that company has connected the Google Map API to its website. Every time the API sends a request to Google, the company pays a small fee for that service.
When you enter your address to get directions, a quick API call is made, sending your address and the business address to Google. The API then sends the directions to get there back and shows the route on your screen.
APIs allow different applications to talk to each other. They are intermediaries that move data back and forth. Explaining API’s is not the scope of this article, but if you need a refresher, this post provides a good overview for non-technical readers.
How do companies use APIs?
In the early days, API’s were designed to create connections between legacy software. They are often used by companies with complex infrastructures. Using certified connectors and application programming interfaces (APIs), human capital management (HCM) and ERP software can integrate seamlessly with other systems like payroll and time & attendance. They enable two-way data transfers that lessen time and manual effort involved in importing and exporting data.
In combination with automated data validation (to check the accuracy and completeness of data that is uploaded to the system), these secure integrations between HR, payroll and time systems help organizations lower processing times, decrease error rates, and eliminate the need for double data entry or reprocessing payrolls. These kind of API’s benefit a company internally: the data is moved between systems that are used by the company alone. Even if these systems are cloud-based or hosted externally, that provider doesn’t have access to the data being processed. They also don’t rely on that data for their value proposition.
Micro-services in the cloud
As companies move their HCM infrastructure to the cloud, they take advantage of modern solutions based on (open) standards. Companies that create these solutions have built-in API’s. They publish these API’s with specifications and requirements, and clarify what access they will allow to their platforms. The customer can use these APIs to eg move data into a data warehouse, or allow a payroll provider to connect with the cloud HCM system and download data for processing purposes while uploading the final results and/or payslips.
Because these specifications are available to everyone, external companies can also use these APIs to build extensions that offer additional functionality, called micro services. They typically bundle a number of API’s from various vendors into one overall App or service. Some of them build functionality for the HR department, while others focus on the employee experience.
Three examples of API services
When you have a job opening, you don’t just want to post it on your company’s website: you want to publish it on external job boards, so your vacancy gets exposure. Most ATS vendors come with built-in API’s to make posting easy. When you are done and push the button, the posting is sent automatically to 3rd party vendors like Monster and others. These systems receive the file, parse the content and publish the vacancy. It’s completely automatic (assuming you’ve paid for your subscription). It works, because the ATS vendor has aligned with the API from the job board and knows exactly which format to use for which job board. And if you don’t have an ATS but still want to publish your vacancy, there are online services that have bundled access to job board API’s. You upload your posting, tick the boxes for the services you want and the vacancy is being sent and published in minutes.
Or take a mortgage approval process. When an employee wants to buy a house, the lender typically requests verification that the person actually has a job, and how much money they make. The HR department can make that information available but that requires manual activities. Suppose the mortgage company could directly verify that information using the employer’s HCM/payroll system, leading to an automatic verification? In that case, the mortgage lender asks the employee to provide their HCM credentials through a secure interface. The established API connection would let them review and verify the information directly on the employer’s HR/payroll system.
The last example concerns a hot topic, financial wellness. What if you could help employees better manage their money? And support them in ensuring they make their mandatory payments on time so they don’t end up paying late fees or fines? Mortgage companies, insurers and others would like to de-risk their outstanding loans by taking payment obligations straight from an employee’s paycheck. The remaining balance is deposited in their bank account. It would mean that the payroll software have API’s with these vendors. And especially in this area, there is so much valuable information contained in payroll data that fintechs are starting to take an interest.
Why are fintechs building payroll APIs?
From the moment I first learned about fintechs, I thought they would have the potential to disrupt payroll. But there is so much to reinvent in banking, and probably with a greater payoff, so the focus hasn’t been on HR. The introduction of Open Banking meant that all eyes were focused on innovating how we use banks and pay for services and goods. And in the meantime, as they were introducing new solutions to consumers, fintechs matured and started to achieve high valuations.
The rise of a host of “Pay me Now” applications is a first indication that fintechs are starting to take an interest in income sources. I wrote an article about that topic and introduced you to some startups innovating payroll.
And then I read two articles that made me realize that a pivot is underway, as fintech companies are starting to take an interest in where those payments originate: enterprise payroll. Here’s a quote from The Promise of Payroll APIs:
The importance of Plaid and the API market more broadly cannot be overstated—an entire generation of neobanks, lenders, and financial management tools have been made possible through programmatic access to bank transaction data.
A new set of platform players are emerging that follow a similar pattern. Much as Plaid allowed consumers to make their bank transaction data available to fintechs, these new platforms are giving fintechs access to payroll, insurance, credit, and ERP data.
The article Payroll Data + Fintech investigates the financial services chain. Currently, if you want to understand the financial status of a person, you look at what they do with their money: spending, saving and investing. But if you want the complete picture, you should actually start up the chain where the income originates: payroll.
Given this, payroll system providers should (in theory) be more willing to build direct integrations and business partnerships with payroll API providers than banks have been with transaction data API providers.
ADP and Paychex and the rest of them have an asset (payroll data) that they can and should want to monetize.
But it’s not that simple: barriers and hurdles
In the mind of these fintechs, payroll data provides a holistic view of a person’s finances. While there may be other income streams, the information resulting from payroll is valuable, and could eg be used as base to decide if people qualify for financial services like loans and mortgages. In this way, accessing payroll data through API’s could provide 3rd parties with insights, and help people unlock financial services.
But fintechs not only earn money because they provide a service: they earn additional money selling insights on the contents of that service. To create these insights, they access the data that flows through these API’s. In the case of banking apps, the information is being used to provide additional services. If customer A buys product 1 and 2, and customer B with the same characteristics only buys product 1, they will recommend them to product 2 as well. When they notice customer B can earn a higher interest rate on savings at a competing financial institute, they will make that information available.
To use Open Banking services, a consumer must give upfront consent to allow a 3rd party access to their data. And because of privacy regulations, that 3rd party must be clear on what they do with that data. And as much as I like the direction of thinking in the two articles, both conveniently omit the topic of privacy. What is technically possible is not always legally feasible. Companies are bound to different standards and need to uphold privacy. When you allow external companies to access an employee’s personal and financial data directly through the HCM or payroll system, that could be a privacy violation or security risk in the making. And with a company’s reputation on the line, the risks might not outweigh the benefits.
From an employee perspective, financial services offered by your employee are a double-edged sword. On the one hand there is an aspect of convenience and the potential for higher discounts. But there is also the nagging feeling that you like to keep some things private. And while lenders might prefer that the money to repay your loan comes straight from your employer, as an employee you probably do not want your employer to know what you spend your money on, or how much debt you have.
A final issue is the duplication of services: there are already apps available that allow an employee to run services against their bank account. The moment their salary is deposited, these apps will distribute the money to the various parties. Why would an employee move that up to their salary? First, chances are they have multiple income streams, which the bank account pools. Secondly, they are much more likely to switch employers than they are to switch bank accounts – and from that perspective it makes much more sense to focus on what is theirs and long-term.
APIs as enablers of a modern HCM ecosystem
At this point you might think that the risks of API’s do not outweigh the benefits, but that’s not true. The better you understand the purpose and potential of an API, the more control you have over it, while also being aware of what’s at stake.
All professional platforms have APIs that you can integrate, automate, and orchestrate with without writing code. APIs make it easier to integrate and connect systems, services and data, create new user experiences, share information and authenticate users. They enable transactions and algorithms and let you offer new services, including the ones I described above.
Using APIs, you can turn your HCM solution into an ecosystem consisting of a variety of vendors and services. When you adopt this approach, you will also be less dependent on one vendor. If you don’t like the service anymore, or a better one becomes available, you can switch out one API for another.
When you access these services directly through the vendor API instead of building your own interface, that will save you time and money. While you pay a small fee every time you access the vendor API, just take a look at this estimate of what it cost to build a bespoke API:
“An enterprise API costs an estimated $25,000-$30,000 to build, and then 50% of that amount per year to manage. Multiply that by 10 APIs and you have $275,000-$450,000 per year just so APIs can exist within your organization. Everyone who wants to access an API must develop, test and implement custom code, at an estimated cost of $15,000 per integration, plus a 50% maintenance fee. Each API must also be secured, costing additional thousands of dollars.”
No matter how sophisticated your HCM solution is, it will never cover all of the services you want to offer to your employees. Sometimes you need to exchange data with another service. Or you want to make a new service available and that vendor only offers it through an API. API’s also make life easier for your employees: by combining the services into a mobile app, you give them one place to go and help themselves.
There are many young companies focused on building new solutions while bundling APIs from a variety of vendors. I’ll introduce you to some of them in the related article. And as you design and build your HR services ecosystem, your pace of innovation will be greatly supported by incorporating them, allowing you to quickly offer modern services that positively enhance the employee experience.