A vendor's sales deck says "99.9% uptime." You sign.

Three months later, the verification API stalls for an hour on a Monday morning. Your onboarding flow slows down, customers abandon their applications, and your support team starts fielding complaints. Then you check the contract. The outage is excluded from the uptime calculation, and the service credits don't come close to covering the disruption.

The gap between what a vendor promises in a sales meeting and what it's contractually required to deliver is exactly why a service level agreement (SLA) matters.

For businesses that rely on KYC APIs, an outage can interrupt onboarding, delay account activation, and cost revenue. Some verification services also depend on government databases the vendor doesn't control. A strong SLA makes these dependencies clear and defines availability, performance, incident response, remedies, and each party's responsibilities when something goes wrong.

If you're evaluating a KYC provider, here are the terms worth examining before you sign.

1. Read the Uptime Guarantee Properly

A 99.9% uptime promise sounds reliable. But what does it allow?

Assumes continuous 24-hour service with no exclusions.

The difference between 99.9% and 99.99% looks small on paper, but it's significant for a fintech processing thousands of verifications a day. And an uptime percentage is only as useful as the contract's definition of availability.

How Is Uptime Measured?

Some vendors measure availability with their own infrastructure monitoring, which can differ from what your customers experience. A provider's servers might be running while your requests keep timing out.

Ask whether availability is based on successful API responses, synthetic monitoring, infrastructure health or another agreed method, and whose records count if there's a dispute.

Is It Measured Monthly or Annually?

An annual guarantee can hide a bad month.

Eight hours of downtime in one 30-day month means about 98.9% availability that month, yet it still fits within a 99.9% annual allowance.

If you depend on continuous onboarding, monthly measurement gives a clearer picture of the service you're receiving.

Does It Cover Every API?

A provider can report strong platform-wide availability while one service fails repeatedly.

Ask whether the guarantee applies to individual services, such as BVN, NIN, document verification, or face matching, or only to the platform as a whole.

What Is Excluded?

Most SLAs exclude scheduled maintenance, upstream provider failures, customer-side configuration problems, and events outside the vendor's reasonable control.

These exclusions aren't unreasonable in themselves, but they must be clearly defined. Ask how much notice you'll get for maintenance and whether excluded outages are still reported.

2. Understand What Happens When Government Data Sources Fail

KYC APIs often depend on external identity databases.

In Nigeria, verification may draw on identity records managed by NIBSS and NIMC through authorised access arrangements. Access to some of these databases is restricted by regulation.

A provider's own systems can be fully operational while an upstream source is down.

Dojah's API error and status code documentation, for example, includes an error for failures involving a dependent data source.

That raises the key contracting question: who is responsible when a verification fails because an upstream source is unavailable?

Your SLA should answer four questions.

What Legal Basis Does the Vendor Have for Each Source?

Ask how the provider is authorised to access the identity databases it uses.

If that access is withdrawn or restricted, the service you're paying for may stop working.

For Nigerian financial institutions, this is especially important when dealing with BVN-related services, given the CBN's restrictions on access to the underlying BVN database.

Your institution should understand the provider's access arrangements before depending on the service.

Are Upstream Outages Excluded From Availability?

If your business relies heavily on one identity service, excluding its downtime could sharply reduce the protection the SLA offers.

Ask which dependencies are excluded, how those failures are reported, and whether the vendor provides alternative recovery arrangements.

Are Failed Requests Billed?

If a government source times out, find out whether your wallet is charged for the failed attempt and for any retry.

Put these terms in the contract or commercial schedule rather than relying on assumptions about API behaviour.

What Happens to Customers During an Outage?

Your onboarding should save the customer's progress, show a pending status, and let verification resume once the service recovers.

Dojah offers EasyOnboard retry functionality for supported scenarios.

Whatever the tooling, your workflow must never treat an incomplete check as a successful one.

For regulated account opening, an upstream outage is not permission to skip mandatory identity checks.

3. Look at Speed and Verification Success, Not Just Availability

An API can be technically available and still perform poorly.

If a check consistently takes 20 seconds instead of two, customers may abandon onboarding even though the provider reports no downtime.

Ask for Response-Time Targets

Request latency targets for the services you'll use:

• Median response time: Shows typical performance.
• 95th-percentile response time: Shows how slower requests perform.
• 99th-percentile response time: Reveals the worst delays a small proportion of users experience.

The contract should explain how these are measured and what's excluded.

Check whether the figures reflect performance from your market. Measurements taken close to the provider's servers may not match what users see on Nigerian mobile networks.

Define Verification Success Correctly

A successful API response doesn't mean the customer's identity was verified.

A valid response might say no matching record was found, which is different from both a network failure and a confirmed identity match.

Ask the vendor to report these separately:

• API availability.
• Technical request success.
• Identity match or verification outcomes.
• Upstream data-source failures.

This stops a high headline success rate from hiding real problems.

Confirm Rate Limits and Capacity

Traffic spikes during marketing campaigns, product launches, and salary periods.

Ask how many requests you can send, how bursts are handled, what happens when you exceed the limit, and whether more capacity costs extra.

4. Check How Quickly Support Must Respond

When onboarding is down, you need more than a general promise that support exists.

Define Severity Levels

A question about an API parameter isn't the same as a production outage blocking thousands of customers.

The agreement should define critical, high, medium, and low-severity incidents, with a response target, escalation path, and restoration commitment for each.

Response time and resolution time are not the same thing.

An acknowledgement within 15 minutes doesn't mean a fix within 15 minutes. Both should be clear.

Confirm Support Hours and Channels

Is support available on weekends, on public holidays, and at midnight?

Which channels can you use: phone, email, chat, or a dedicated support channel?

Most importantly, which one officially starts the SLA clock?

A message in a community chat may not count as an incident report unless the contract says so.

Establish Escalation Contacts

Know who to contact when first-line support can't resolve an incident.

For critical services, ask for a named escalation path covering technical support, incident management, and account ownership.

This matters most when an upstream failure involves several parties.

5. Examine Service Credits and Other Remedies

An SLA without meaningful remedies offers limited protection.

How Are Credits Calculated?

Some providers credit a percentage of the monthly fee; others credit only the affected service.

Ask what triggers a credit, which charges it applies to, and whether there's a cap.

A 5% credit may be trivial compared with the cost of a major outage.

Are Credits Automatic?

Some contracts require you to claim within a set period or lose the credit.

Check how claims work and what evidence you'll need.

What Does Downtime Actually Cost You?

Take a fintech that receives 120 sign-up attempts an hour and completes 60% of them.

A one-hour outage puts about 72 expected completed signups at risk.

Some of those customers will come back later and some won't, but the disruption has a real commercial cost.

Compare the potential onboarding impact, additional support workload, and recovery effort with what the SLA offers.

What Happens After Repeated Failures?

One missed target may be manageable; months of outages are not.

Check for stronger remedies for recurring breaches, such as escalation, higher credits, or termination rights.

Also review liability limits and whether credits are your only remedy.

A generous credit clause is worth less if the contract blocks recovery for other losses.

6. Require Clear Incident Communication

During a major outage, uncertainty makes things worse.

Support needs information for customers, engineering needs to know whose side the problem is on, and management needs to understand the impact.

Your SLA should set out:

• How quickly the vendor must notify you of a significant incident.
• Which channels it will use.
• How often it will send updates.
• Whether there's a public status page.
• When you'll receive a written incident report.
• How planned maintenance will be announced.

After a serious outage, the vendor should explain what happened, how long it lasted, the impact, the root cause, and the corrective actions.

That tells you whether you need additional safeguards.

Notice of Changes

Outages aren't the only disruption. API changes, version deprecations, and price changes can break integrations or budgets.

Agree on minimum notice periods for each, so your engineering and finance teams have time to adapt.

Business Continuity and Disaster Recovery

Ask what happens if the provider suffers a major failure, not just a brief outage.

The contract should state a Recovery Time Objective (RTO), which describes how quickly service should be restored, and a Recovery Point Objective (RPO), which describes how much data loss the recovery arrangements are designed to tolerate.

Ask whether the vendor's continuity arrangements have been independently assessed and how often recovery plans are tested.

7. Check Data Protection and Security Terms

A KYC provider processes some of your customers' most sensitive information: identity numbers, photographs, ID documents and sometimes biometric data.

The contract must cover how that information is collected, processed, stored, accessed, and deleted.

In Nigeria, the Nigeria Data Protection Act 2023 sets obligations for data controllers and processors.

Make Sure the Processing Agreement Is Clear

Section 29 establishes obligations for controllers engaging processors, including appropriate written arrangements and measures to ensure processors assist with compliance.

For a KYC provider, the agreement should set out:

• The categories of personal data processed.
• The purpose and duration of processing.
• Each party's responsibilities as controller or processor.
• Security measures and access restrictions.
• The use of subprocessors, including notice of changes.
• Retention and deletion procedures.
• Cooperation with audits, investigations and data-subject requests.
• How data is handled when the relationship ends.

Set a Clear Breach Notification Deadline

Section 40 requires a processor to notify the controller when it becomes aware of a personal data breach.

A controller must notify the Nigeria Data Protection Commission within 72 hours of becoming aware of a breach likely to put individuals' rights and freedoms at risk. Affected individuals must also be notified where the applicable high-risk threshold is met.

Your agreement should require prompt vendor notification, relevant incident details and cooperation with your investigation, so you have time to meet your own obligations.

Know Where Customer Data Is Stored

Ask where verification data and backups are hosted, which subprocessors can access them and whether any data leaves Nigeria.

Cross-border transfers must satisfy the NDPA's requirements.

For ID documents and biometrics, confirm the retention period and how deletion works.

Dojah's file-link documentation, for example, explains that temporary verification file URLs expire within about an hour.

If your business needs to retain these files, download them securely before the links expire and apply your own retention and access controls.

The documentation also describes how a fresh link can be retrieved using a verification reference.

The contract should separately establish what information Dojah retains, for how long, and how it is protected.

Ask for Evidence of Security Assurance

Ask which independent certifications the provider holds, such as ISO 27001 for information security, and request current certificates or audit reports rather than relying solely on logos on a website.

Check whether you have the right to audit, how often penetration testing happens, and whether relevant results are shared.

8. Check the Regulatory Requirements That Apply to Your Vendor

For CBN-regulated institutions, KYC vendor risk is also a regulatory matter.

The CBN's March 2026 Baseline Standards for Automated AML/CFT/CPF Solutions identify customer identification and verification, including remote onboarding, as functions within an institution's AML control environment.

If your KYC provider supports those functions, its service should be assessed as part of your institution's wider AML controls.

Several requirements are particularly relevant to vendor contracts.

• Resilience: Institutions need availability, resilience and disaster recovery arrangements that protect critical AML functions during outages or migrations.
• Recovery targets: AML systems need defined recovery objectives informed by business impact analysis.
• Vendor management: Institutions need a vendor management framework covering procurement, implementation, support, change management, incident handling, and exit.
• Data protection: Processing and storage must comply with Nigerian data protection and sovereignty requirements.

The scope depends on the role the provider plays in your compliance setup. A standalone KYC API contract is not automatically subject to every provision governing a complete automated AML solution.

Regulated businesses should also consider the outsourcing, cybersecurity and operational resilience obligations attached to their activities.

The practical test is the same either way:

Can you show that your provider is properly governed, customer data is protected, failures are managed, and you can keep meeting your obligations if the provider becomes unavailable?

Your SLA should support that answer before you sign.

9. Plan Your Exit Before You Enter

Most businesses focus on integration when choosing a provider. Few think about leaving.

But changing providers affects customer records, verification evidence, integrations, and live onboarding.

Your contract should make that transition manageable.

Data Export

Confirm which records you can export, in what formats and how quickly.

Check that exports include verification outcomes, timestamps, identifiers, references, audit histories and supporting documents, so you can keep the evidence your legal and regulatory obligations require.

Transition Support

Migrations often mean running two providers at once.

Ask whether the current vendor will keep serving you during the switch, what technical help is available, what it costs, and what happens to prepaid balances, unused credits and outstanding invoices.

Deletion and Retention

After migration, the vendor should return or delete your data in line with the agreed schedule and confirm it in writing.

Identify any records it must keep by law and how they'll stay protected.

For a practical migration plan, see our guide to switching KYC providers without disrupting customer onboarding.

10. The KYC API SLA Checklist

Use this checklist when Legal, Compliance, Engineering, and Procurement review the contract together.

If a critical term is missing, ask for written clarification or an amendment rather than relying on verbal assurances.

How Dojah Supports Your SLA Evaluation

Choosing a KYC provider goes beyond comparing verification coverage and pricing. Businesses also need reliable infrastructure, visibility into service performance, and clear commitments before going live.

Dojah addresses these requirements through its service level agreement, security controls, monitoring tools, and developer resources.

Businesses complete account verification and sign an SLA before moving from sandbox to live access.

Here's what that means for businesses evaluating Dojah.

• 99.9% Uptime and Security Assurance

Dojah provides a 99.9% uptime guarantee, supported by security, business continuity and service management controls.

The Trust Center provides information on compliance with standards and frameworks including ISO 27001, ISO 22301, ISO 20000 and SOC 2.

Businesses can review the available security information and request supporting certification or assessment documents during their vendor evaluation.

• Visibility Into API Performance

Dojah's API Status dashboard provides visibility into the health of individual verification services.

It displays current service status, recent availability information, and reported incidents, helping technical teams monitor performance and investigate service interruptions.

When an API request fails, businesses can compare the reported service status with their own application logs to identify the cause and determine the next action.

• Integration, Troubleshooting and Recovery Tools

Dojah provides developers with tools to test integrations, investigate errors, and monitor API activity.

The API error and status code guide explains common failures, including authentication errors, rate limits, insufficient balance, and upstream data-source issues.

The sandbox environment allows developers to test supported verification requests using mock data before moving to production.

Once live, businesses can use API Logs and Usage tools to review requests, monitor response codes, investigate failed verifications, and reconcile usage costs.

These resources help businesses maintain visibility into verification activity and resolve integration issues more efficiently.

• Billing That Supports Continuous Onboarding

Dojah's production APIs operate through a prepaid wallet.

Auto top-up functionality allows businesses to configure automatic wallet funding when their balance reaches a specified threshold.

For businesses processing high volumes of verification requests, this helps prevent onboarding interruptions caused by insufficient wallet funds.

• Clear Service Commitments Before Going Live

Dojah's SLA provides businesses with an opportunity to review the contractual terms governing their verification services before production access is activated.

Businesses can assess the uptime commitment, support arrangements, upstream dependencies, incident management, and contractual remedies as part of their procurement process.

Dojah's team can also clarify the specific terms of the agreement, helping businesses understand the commitments behind the verification infrastructure they depend on.

A Strong SLA Is Part of a Reliable Onboarding Experience

Choosing a KYC API isn't only about coverage, pricing, or integration speed. It's also about knowing what happens when verification slows down, an upstream source fails, or a critical incident disrupts onboarding.

A strong SLA establishes clear expectations for service availability, performance, support, and accountability. It gives businesses a basis for evaluating providers and protecting their onboarding operations.

That's why reviewing the SLA deserves as much attention as evaluating the API itself.

Reliable identity verification needs reliable commitments behind it.

Explore Dojah's identity verification solutions and speak with the team about the verification services and SLA terms that fit your business.

Frequently Asked Questions

• What Is a Good Uptime SLA for a KYC API?

There's no universal target.

A 99.9% annual guarantee allows about 8.76 hours of downtime a year; 99.99% allows about 53 minutes.

The measurement period, exclusions, and which APIs are covered matter as much as the percentage.

• Do KYC API SLAs Cover Government Data Source Outages?

Not always. Many providers exclude some upstream incidents from their availability commitments.

Check how upstream failures are measured, reported, and billed, what recovery options exist, and how the provider is authorised to access each source.

• What Should I Check Besides Uptime?

Response times, success definitions, support commitments, incident communication, change notice, disaster recovery, service credits, data protection, security assurance, billing and exit terms.

• Are Service Credits Enough to Protect My Business?

Not necessarily.

Credits are usually a percentage of fees paid, not the full cost of an outage.

Review them alongside termination rights, liability limits, and other remedies.

• Do the CBN's Automated AML Standards Apply to KYC API Providers?

They can be relevant where a KYC provider supports an institution's automated AML environment.

The March 2026 Baseline Standards include customer identification and verification among the core AML functions and establish requirements for resilience, vendor management and other controls.

The institution must assess which requirements apply to its use of the service. Not every standalone KYC API contract falls under every provision of the standards.

• What Should Happen to Customer Data When a KYC Vendor Contract Ends?

The contract should cover export, retention, return or deletion, and transition support.

You must be able to keep records the law requires, while your former provider handles any data it retains securely.

• How Can I Monitor Whether My KYC Provider Meets Its SLA?

Keep your own logs of requests, response times, errors, and failed verifications.

Compare them with the provider's API status information and the contractually agreed measurement method.

That gives you evidence for troubleshooting, performance reviews and service-credit claims.