Skip navigation EPAM

Utilizing an API-First Mindset in Underwriting Portal Development

Utilizing an API-First Mindset in Underwriting Portal Development

Underwriting portals are a valuable tool to keep insurers organized and connected with brokers and customers, but only if they’re built to deliver a best-in-class experience and seamless workflow. Taking an API-first approach, insurers can accomplish just that.

The process to build a portal can be complicated and, therefore, it can be extremely tempting to copy the standard offerings in the marketplace. But this plug-and-play approach can create a disjointed experience in the long run and make a monumental impact downstream.

Adopting an API-first, top-down framework enables companies to build a portal’s distribution strategy around the API landscape, focusing on efficiency within data deconstruction and storage, ultimately helping to reduce costs, speed time to market and allow development teams to work in parallel.

To develop a reliable, predictable interface and maximize both consumer and developer efficiency, APIs should always be designed with the consumer in mind. An abstract API layer using API management technology hides the complexity from the consumer and facilitates underlying systems of record replacement. APIs make the processing of the volume of new business applications more manageable by:

  • Efficiently automating applicant data ingestion.
  • Conducting data validation with third-party aggregators.
  • Utilizing straight-through processing to reduce processing times and communication touchpoints for customers, brokers and underwriters.

All too often, however, the teams tasked with these projects are working with a tight budget and expedited timeline to get a portal built, tested and implemented. Because of this pressure, it can be enticing to connect and repurpose existing systems (like turning a claims system into an underwriting platform) for speed and cost efficiency. However, this creates a poorly executed portal design and architectural solutions that will eventually require extensive software patch jobs and frequent bug fixes.

The ability to create a strategic vision for successfully designing a portal with the appropriate architecture, workflow, data mapping and APIs is what sets apart the leading insurance products that attract the most profitable submissions from the rest of the competition. Because APIs allow different applications to communicate and exchange data, this increases the efficiency of the portal’s architecture, workflow and data mapping while collecting the minimum amount of information on a customer to accurately price the risk of the insurance product they are looking for. 

Focusing an API-first Approach to Design and Development

Before the developers begin to write their first lines of code, insurance companies should consider five key steps to designing a portal with an API-first mindset:

  1. Profile internal and external customer expectations to create an appropriate user experience. 
  2. Design a simple workflow that will bring brokers back with repeat business. 
  3. Create a frontend interface that maximizes API use and minimizes manual entry.
  4. Ensure environmental control with developers.
  5. Conduct a source-to-target mapping exercise aligning underwriting and policy administration systems.

Step 1: Profile internal and external customer expectations to create an appropriate user experience. 

Understanding how both parties want to interact within the portal is a core design feature that must be envisioned as early in the portal planning and construction process as possible. Begin with identifying the end customer. What product(s) are they buying? What is the price sensitivity of the customer and how quickly are they looking to make a purchase? 

On the internal side, what the underwriters are looking to receive as output is an important portal consideration. Depending on the complexity of the risk, most of the output (if not all) can be fully automated with predetermined system notifications that are sent directly to the underwriter with risk thresholds, geographic location, premium levels or any other important classifications. For more complex risks, the portal can gather core information quickly and then notify the underwriter about additional data that’s required from the broker/customer. 

It’s important to remember the product can achieve best-in-class functionality over time. The backend workflow of data transfer to various internal systems doesn’t need to be perfect before it’s rolled out to the market. What does need to be perfect is the product’s user interface for the broker/customer. This must always be optimized from a user experience perspective to differentiate the portal from the competition. 

Step 2: Design a simple workflow that will bring brokers back with repeat business. 

Set targets for application submission times, such as 20 minutes from start to finish for frequently sold risk products. For a company trying to write thousands of policies a year, the 20-minute goal should be built into overall underwriting design.

Establish guardrails for the data validation strategy to immediately stop applications that will not be written, saving time for the broker/customer. Companies that aren’t willing to take on certain risk profiles can prevent the broker or customer from filling out the application by setting specific rules and parameters within the product.

Usability is a vital part of repeat business. By creating a straightforward navigation bar and data collection workflow, companies make it easy for the broker/customer to intuitively know where they are in the application process.

Factored together, these design elements can make a company’s product the first stop for brokers or customers to obtain a quote and place business.

Step 3: Create integration points that maximize API use and minimize manual entry.

The best underwriting portals leverage optical character recognition (OCR), data standardization (addresses and account numbers) and other smart document intake of uploaded forms and PDF files to scrape data and intelligently direct information to pre-determined backend database fields. This is all completed without the broker/customer manually inputting data. Instead, the focus is on the APIs pulling in and directing the data to appropriate fields, with the broker/customer then confirming its validity with a simple click.

This can be developed by establishing a standard API interface that can integrate with brokers and third-party vendors, such as OCR providers, data validators, risk vendors and document tools. The layering that occurs as more partners connect to the API provides the underwriter with a better view of the customer.

Step 4: Ensure environmental control with developers.

To align with other digital transformation initiatives run through a company’s IT organization or by an outsourced team, it’s important to create a governance framework to control code merges, release schedules, testing, quality gates and bug fixes/refinement.

While they should align with other projects, underwriting portals do still require individual, isolated product development. This includes running the portal with the same product management principles that are used in both software development and insurance products alike. The entire development and interaction lifecycle — from vision, through execution, to customer reaction — should be considered. 

The product owner, scrum master and development team should have a shared vision that is outcome based, ensuring that the team is delivering maximum value to customers. This value can later translate to increased usage and revenue.

Step 5: Conduct a source-to-target mapping exercise aligning underwriting and policy administration systems.

Avoid wasting broker input time on collecting data that isn’t needed. Align the frontend fields to only capture what is necessary for field population in underwriting and policy administration systems and policy contractual language. 

By using APIs to integrate with enterprise content management capabilities, companies introduce the ability to centralize document generation, which ends up being the insurance product output. The benefit for companies is the consolidation and standardization of the content, look and feel of documents generated from the core platforms to match corporate branding.

Final Thoughts on Underwriting Portal Development

When building an underwriting portal, use a best-in-class user experience and seamless workflow to impress your end customer. Execute this strategy by designing a solution framework that uses an API-first approach to efficiently capture and direct data through automation, minimizing manual inputs.

Bottom-line benefits will be realized through the ability to process and quote more applications, the speed and accuracy of data retrieval through APIs, and standardized output with notifications for underwriters. Successfully completing this objective is a monumental task, but it can be executed with the proper strategy and vision. 


Hi! We’d love to hear from you.

Want to talk to us about your business needs?