What happens when an identity verification provider goes down? | Trust Infrastructure Explained

Key points

• Each verification method is delivered by one or more providers. Using several providers for the same method lets users be routed to another provider when one fails.
• Failover works at two levels: a comparable provider for the same method, or another method that returns an equivalent data set in the same country. For many methods, only the second level exists.
• Provider risk goes beyond outages. A provider can withdraw from a market or change its pricing, and someone then has to integrate a replacement.
• Behaviour on provider failure is best decided at integration time. Pinning a single provider removes the alternative route for that method.
• Authologic sets the failure scenario per customer and notifies customers directly instead of through a public status page.

What sits behind an identity verification method?

In this text, the customer is the business that runs identity verification, and the user is the person being verified.

A verification method is the way the user proves their identity, for example a national eID, a bank ID, a PSD2-based account check or a document check with biometrics.

Each verification method is delivered by one or more providers.

A customer can integrate each provider directly, or connect through an orchestration platform that routes users across several methods and providers behind one integration.

Routing and fallback are defined in the Identity Orchestration Glossary.

What can go wrong with an identity verification provider?

An identity verification provider can fail in more than one way.

It can be unavailable, after a sudden outage or during planned maintenance. It can stop passing traffic from a country or for a document type it used to support. A country can also stay officially supported while traffic from it is blocked at the technical level. It can withdraw from a market, or change its pricing so that continuing no longer makes economic sense.

Each of these failures leaves users without a route through that provider, and each needs a different response: a temporary redirect for an outage, a change of route for a country, a migration to another provider for a withdrawal.

How does failover work in identity verification?

Failover in identity verification works at two levels:

1. Where comparable providers exist for the same method, a second provider can take over, or both can run in parallel.
2. Where they do not, the alternative is another method that returns an equivalent data set in the same country.

For many methods, only the second level is available.

The practical starting point for resilience is therefore the data set a customer needs, with methods chosen to deliver it in each country.

Running comparable providers in parallel means capacity is already in place, instead of a fallback that has to be triggered.

Providers of the same method also differ in effectiveness and quality from market to market, so parallel providers let traffic go to the one that performs better where the user comes from. Parallel providers also give users, or the customer's system, a choice of route, which supports conversion.

Should you pin a single identity verification provider?

Pinning a single provider is the configuration to choose when a regulatory position, an internal policy or an existing contract ties a customer to a named provider. Pinning means accepting that if the provider is unavailable, there is no alternative route for that method.

The trade-off between a named provider and an alternative route is easier to settle at integration time than during an incident.

How do providers communicate incidents?

Providers communicate incidents in two main ways: a public status page that anyone can check, or direct notifications to each customer by email, chat or phone.

A public status page lists everything.

Direct notifications can be filtered to the methods and connections a customer actually uses.

What does an SLA cover?

An SLA is set in each customer's agreement, and its definitions differ between contracts.

An orchestration platform can commit to the availability of its own platform. It cannot give guarantees on behalf of the third-party providers behind each method.

How does Authologic handle provider failure?

Authologic routes each user to a verification method, and each method is delivered by one or more providers.

Behaviour on provider failure is configured per customer account and contract, and we advise deciding on it early in setup, in case users need to be redirected to another method.

Three failure scenarios

1. Several methods offered to the user. When our monitoring shows that a connection is unavailable, our team reacts and takes the next steps agreed with the customer, for example removing that connection from the list the user sees.
2. The choice left to the customer's system. Authologic provides the available connections through the API, and the customer's system decides which provider to call.
3. One method in focus. The customer decides whether and when to show or hide that method.

In each scenario, Authologic provides the connections, monitors them and informs the customer when a method is unavailable.

Notifications instead of a status page

A generic status page is not always the most useful tool. To be honest, we do not have a public status page today, but we make sure you do not miss anything important.

Authologic informs you through the channel you prefer.

Most of our customers use both email and Slack, and in emergencies we call. Notifications are filtered to what affects you, so you do not receive messages about methods you do not use or maintenance that does not touch your connection.

Precise, targeted information is part of how we work.

Pinning a provider

A customer can enforce a specific provider and a specific method, provided that provider is covered by the agreement.

We are happy to discuss the pros and cons of individual methods with you. If regulatory or other requirements mean you need to limit yourself to specific providers, we offer that option. Our role is to advise and give you choices, and the decision on where traffic goes is always yours.

In a crisis we will still offer alternatives. Switching them on requires an update to the agreement and to the account settings, so it takes longer.

Parallel providers

Where comparable providers exist for the same method, Authologic runs them in parallel rather than one waiting behind the other.

This is already the case for biometrics and AML checks, where traffic goes to the provider that performs better in the region the user comes from.

For PSD2-based verification, comparable providers operate inside the same flow.

When a provider withdraws from a market

Authologic switches the affected customers to a comparable provider.

We have done it before, including once when a provider's pricing made continuing uneconomic although the provider stayed in the market. We have also built new connections and handled both sudden and planned outages.

Finding a comparable provider, integrating it and migrating live customer traffic is an engineering effort that has to happen somewhere. On a direct integration it lands on your team, at a time you did not choose.

With Authologic it lands on ours.

We contact you, explain the situation and make sure the contract covers the change, while the technical work stays with us, because our API abstracts away the differences between providers.

You do not need to change anything in your integration.

API availability

Over the past 12 months, Authologic's API availability was 99.998%.

Excluding announced maintenance windows, it was 100%.

SLA terms are set in each customer's agreement and cover the Authologic platform. Authologic cannot give guarantees on behalf of the third-party providers behind each method.

What to ask an identity verification provider about failover

The answers depend on your configuration rather than on a general policy, so these questions are worth asking any provider directly:

• Which methods in my markets return the data set I need, and which of them are served by more than one provider?
• What happens to my users' flow when a provider is unavailable, and who decides where they are redirected?
• Who detects a provider failure, and how quickly is the route changed?
• Which providers does my agreement cover, and what would it take to add one during a crisis?
• How will I be told about incidents and provider changes, and who on my side receives the notifications?
• What does the SLA cover, and what does it exclude?

Changelog

• 12 October 2026 - First publication.