The provider dependency problem
A financial institution does not operate in isolation. Identity verification comes from one provider. Credit risk scores come from another. Sanctions screening from a third. Fraud signals from a fourth. Device intelligence from a fifth. Each of these providers is essential, and each one delivers data in a format designed for their own system, not yours.
This creates a dependency chain where the institution’s ability to make decisions (approve an application, flag a transaction, file a regulatory report) depends on integrating data from providers who have no incentive to align with each other.
When a KYC provider delivers an identity verification result, that result might come as a JSON payload with nested objects for each verification check, or as an XML document following their proprietary schema, or as a webhook with a flat set of key-value pairs. The identity confidence score might be a percentage, a decimal between 0 and 1, a letter grade, or a proprietary tier label. The address verification result might be a pass/fail flag, a match percentage, a multi-field comparison breakdown, or an encoded string that requires their documentation to interpret.
Multiply this by every provider the institution relies on, and the integration surface area becomes a major operational burden.
Format and schema challenges across providers
Each category of external data provider brings specific integration headaches.
Identity verification providers like LexisNexis and similar services return results in proprietary formats that reflect their internal data models. One provider structures identity matches as a list of contributing data sources with individual match scores. Another returns a single composite score with flag codes indicating which checks passed or failed. A third provides separate verification objects for name, address, date of birth, and government ID, each with their own status taxonomy.
The same person verified through two different providers produces two structurally different records that both mean “identity confirmed.” Combining these into a single identity verification status for your system requires understanding not just the field mapping but the scoring methodology.
Fraud detection and risk scoring providers deliver signals in formats that reflect their detection models. One provider returns a risk score from 0 to 999. Another uses 0 to 100. A third returns a risk level (“low,” “medium,” “high,” “critical”) with contributing factors as a nested array. A fourth returns a set of binary flags: is_bot, is_proxy, is_emulator, velocity_trigger.
Normalizing these into a consistent risk signal that your decisioning engine can consume means defining how a 750 on one provider’s scale compares to a 62 on another’s. These are not equivalent scales. They measure different things using different methodologies. The mapping is not just structural; it requires domain knowledge about what each provider’s score actually represents.
Sanctions and watchlist screening providers return match results with varying confidence indicators. One provider returns exact matches and fuzzy matches with a similarity percentage. Another returns match codes: “EXACT,” “STRONG,” “WEAK,” “PHONETIC.” A third returns the full watchlist entry with highlighted match fields, leaving the institution to determine match strength. The entity types (individual, organization, vessel, aircraft) use different taxonomies across providers.
Regulatory and compliance data feeds from sources like FinCEN deliver structured reports in mandated formats, but those formats change with regulatory updates. A new FinCEN requirement might add fields, change field definitions, or restructure the submission format. The institution needs to absorb these changes without breaking existing workflows.
The entity normalization challenge
Across all these providers, the fundamental challenge is entity resolution: making sure that records from different providers about the same entity actually get connected.
Provider A identifies a person by Social Security Number. Provider B uses their internal customer reference. Provider C uses a combination of name and date of birth. Provider D uses the institution’s application ID, which the institution passed to them during the API call.
Joining results from these providers requires a crosswalk — a set of identifier mappings that connect each provider’s reference to the institution’s canonical entity. When identifiers overlap, the join is straightforward. When they do not, the join depends on matching on secondary attributes (name, address, date of birth) with fuzzy logic to handle variations.
datathere’s multi-source join capability handles this by allowing join conditions based on any combination of fields, with transformation expressions for normalization. A join between Provider A’s record (identified by SSN) and Provider B’s record (identified by last name, date of birth, and postal code) uses matching rules that normalize name formats, date formats, and address formats before comparison.
Timestamp alignment and data freshness
External providers respond at different speeds and report with different timestamp conventions. An identity verification result might return in 200 milliseconds. A comprehensive background check might take 48 hours. A sanctions screening result might be near-instant for clean matches and delayed for manual review cases.
When these results feed into a decisioning workflow, the timestamps need to make sense together. A risk score generated at 9:00 AM, an identity verification completed at 8:45 AM, and a sanctions screening completed at 9:30 AM all contribute to a decision about the same application. The composite record needs to reflect when each component was generated, not just when the institution received it.
Provider timestamps might be in UTC, local time, or ambiguous. Some providers include timezone offsets. Others do not. Some report in ISO 8601 format. Others use Unix timestamps. Others use regional date formats where “03/07/2026” could be March 7th or July 3rd depending on the provider’s locale.
Aligning these into a consistent temporal record is a mapping and transformation problem that gets handled once per provider, not once per record.
Practical use cases
Switching providers without rebuilding. When an institution decides to replace a KYC provider (due to cost, coverage, accuracy, or contractual reasons), the new provider’s data format is different. Without a mapping layer, this means updating every system that consumed the old provider’s data. With a mapping layer, it means defining new source mappings to the same canonical identity verification schema. Downstream systems see no change. The switch happens at the integration layer, not at the application layer.
Feeding case management systems. Compliance analysts investigate alerts from multiple providers using a case management tool. When the data from each provider arrives in a different format, the case management system either needs custom integrations for each provider or receives pre-normalized data through a mapping layer. The latter means the case management system has one integration to maintain, regardless of how many providers feed into it.
Regulatory reporting with multi-provider data. A Suspicious Activity Report requires data elements that originate from different providers: identity details from the KYC provider, transaction patterns from the fraud detection provider, account details from the core system. Assembling this report means joining data across providers into the regulatory submission format. When the data is already normalized to a canonical schema, the regulatory report is a transformation of that schema. When it is not, the regulatory report becomes a bespoke aggregation project.
Provider redundancy and fallback. Institutions that use multiple providers for the same function (two identity verification services, two fraud scoring services) need to normalize results from both into a comparable format. When Provider A is down, Provider B’s results need to slot into the same downstream workflow without manual intervention. This only works when both providers’ outputs map to the same canonical structure.
The cost of provider-specific integrations
Every external provider integration built as a custom, provider-specific pipeline creates a maintenance liability. The provider changes their API version, and your integration breaks. The provider adds new fields, and you miss data you should be capturing. The provider deprecates an endpoint, and you scramble to update before the cutoff.
These are not hypothetical scenarios. Major KYC and risk data providers update their APIs and response formats regularly. An institution with custom integrations to eight providers needs to track and respond to schema changes across all eight, each on the provider’s timeline.
A platform approach absorbs these changes at the mapping layer. When a provider updates their response format, the source schema gets updated and the mappings get adjusted. The canonical schema does not change. Downstream systems do not change. The blast radius of a provider update is contained to the mapping configuration, not spread across every consuming application.
datathere handles this by treating each provider feed as a source with its own schema. AI-generated mappings translate provider-specific fields and structures to the institution’s canonical schemas for identity, risk, and compliance data. When a provider changes their format, the mappings are updated and re-certified. When a provider is replaced entirely, new mappings are created for the replacement provider’s format targeting the same destination schema. The institution’s internal systems never see the difference.