One controlled exit for an insurer's calls to regulatory authorities

Context

Insurers depend on a regulatory authority’s services in core processes such as policies and claims: queries, policy verification and similar checks are called by many applications, often in parallel. When each of those applications reaches the authority directly over the internet, security, visibility and cost all become hard to control.

That was the situation here. Several of the insurer’s applications called the authority’s services directly, with no central layer for outbound traffic, so the traffic was unmonitored and hard to control. The rate limits the authority enforces per organisation, and the credentials each application needed to reach it, called for a central and more secure approach.

The constraints

• No central view of outbound traffic to the authority’s services
• No early warning as calls approached the authority’s rate limits on obtaining tokens
• Usernames and passwords for the authority held statically in application integrations
• Duplicate calls with the same parameters, costing both performance and money
• No central logging or dashboard for analysing traffic to the authority

Our approach

1. A dedicated gateway in the DMZ. A dedicated API gateway was deployed on a virtual machine in the DMZ. The gateway reached the authority’s services over the internet and passed the answers back to internal systems.
2. Every application through the gateway. Instead of calling the authority directly, every application was pointed at the authority’s endpoints published on the gateway.
3. Credentials out of the applications. The gateway read the credentials for the authority from a privileged access vault at runtime, and usernames and passwords were taken out of application code entirely. They can be rotated without changing any application.
4. Tokens cached for their lifetime. The gateway cached the token it obtained from the authority’s token service and did not ask for a new one while it was still valid.
5. Repeated requests answered from cache. Requests with the same parameters were answered from a response cache, so duplicate calls were not sent. Chargeable answers, especially those returned for queries through third-party channels, were cached too, avoiding repeat queries and their extra cost.
6. The authority’s limits enforced at the gateway. The rate limits the authority applies were defined on the gateway, with alerts raised before traffic reached them. Traffic can be prioritised per application, so that running out of the authority’s quota does not hold up critical business processes.
7. Logs and dashboards for all of it. Detailed logging and dashboards were set up for all traffic to the authority.

The result

Calls to the authority moved from uncontrolled outbound traffic to one central, secure and observable exit. Rate limits were managed before they were reached, credentials were held in a vault instead of in applications, and fewer duplicate calls brought gains in both performance and cost. Answering repeated queries from cache also used less of the authority’s rate limit and shortened response times. Operations teams could follow the authority traffic end to end.

The pattern is not specific to this authority. A central outbound gateway with vault-based credentials, rate limiting and response caching can be applied to any outbound API traffic, such as interbank integrations, payment infrastructure or other regulatory services.