The concept of “digital transformation” first arrived in the insurance industry almost 20 years ago. Despite the maturity of the term, primary value streams at many insurers are still a far cry from being transformed. Submission intake and underwriting are often still document-based and rife with analog processing, as is claims handling.
Well integrated, automated, and efficient systems are essential for digital transformation. Two technologies we often see used in this context are application programming interfaces (APIs) and robotic process automation (RPA).
An API is a mechanism that allows different software applications to talk to one other, enabling exchange of data and functionality. While the term API has been in business lexicon only for the last 10 years or so, APIs are as old as software itself.
RPA is the use of software “bots” to automate repetitive tasks within business processes, with the goal of improving efficiency and reducing human labor. Automation of tasks involves interacting with business applications, either via API (if available) or via their user interface. This is a key distinction. RPA allows for user-interface-level integration between applications. This approach was known as “screen-scraping,” when user interfaces were made of green screens, but the approach works with web pages and some legacy client/server technology (C++, Delphi, PowerBuilder, etc.). RPA is also not new technology, despite being subject to several marketing makeovers over the years.
User interface integration has downsides. It can be slow and inefficient, especially when many screens/pages need to be navigated to accomplish a task. User interface integration can also be fragile, breaking if a user interface changes unexpectedly.
While RPA and APIs have overlap in terms of integration use-cases, one is not a “drop-in” replacement for the other. Generally speaking, integration with APIs is often preferred; it is more flexible, scalable, and less fragile. It should always be the first option considered. However, API integration isn’t always feasible or practical for technical and economic reasons.
For example, if the system to be integrated is legacy, proprietary, or otherwise not under your control (a partner’s portal for example), APIs may not be an option (unless you can coerce the partner into building them for you, and you are prepared to wait).
Building APIs on proprietary systems is sometimes an option, but the integration point for these is often the database. As such, they bypass business logic (processing rules and edits) in the application. This leads to duplicated/redundant logic in your API (making change harder) and/or data quality issues.
APIs are most appropriate when they are provided by a vendor or when you have control over the application and the application’s business logic rather than the database.
In cases when building an API isn’t feasible, RPA can offer an alternative means to integrating with the application. Because RPA can interact directly with the user interface, just as a user would, all validation, rules, and processing logic are executed. It is possible, even desirable, to publish RPA bots as APIs, thereby allowing other applications to call their functionality as needed.
Rather than competitors, RPA and API should be viewed as complementary technologies. RPA is a tool that can help with many inefficiencies that business operations face. Many insurers have deployed it successfully for “quick wins” and otherwise. But because of its shortcomings―notably its fragility―it may be considered it a Band-Aid on the path toward native digital transformation. But for insurers with a significant legacy portfolio, the Band-Aids may need to last many years. An effective operating model for RPA is critical.
RPA is also a component in the hyperautomation movement. Given the current state of digital transformation at many insurers, hyperautomation is likely to be an area of significant interest in 2024 and beyond.
