KYC and AML pipelines occupy an unusual position in a regulated platform. They handle some of the most sensitive personal data the firm holds, they produce decisions with direct regulatory weight, and they are almost always assembled from third-party services stitched together by internal glue code written under onboarding deadlines. They also fail quietly: when a screening pipeline degrades, nothing goes down, no customer complains, and the first signal is often a supervisory question months later.
These are the weaknesses we encounter most consistently when assessing identity and screening integrations.
Document and biometric artefact handling
Verification produces high-value artefacts: passport and licence images, selfie captures, liveness video, proof of address documents. The recurring findings are mundane and serious. Artefacts stored in object storage with predictable keys and long-lived signed URLs. Copies retained in a staging bucket after the pipeline moved to a new provider. Support tooling that renders the document inline without an access log. Non-production environments seeded with real verification data because synthetic data made testing harder.
Test the retrieval path specifically. Verification artefacts are frequently fetched through an endpoint that authenticates the caller and then serves whichever artefact identifier was requested — the same broken object level authorisation pattern as anywhere else, applied to the most sensitive data on the platform.
Screening decision integrity
A screening result is a decision record, and decision records need integrity guarantees that ordinary application data does not. The questions worth asking:
- Can a screening result be modified after it is written, and by whom?
- Can a check be re-run repeatedly until it returns a favourable result, and is every attempt recorded or only the last?
- Is the decision stored with the inputs that produced it, or only the outcome?
- Can an operator override a decision, and does the override leave a distinguishable record?
The re-run pattern is common and rarely deliberate. A retry mechanism intended to handle provider timeouts also happens to allow repeated submission with adjusted name spellings, and because only the final result is persisted, the audit trail shows a clean pass. From a security perspective this is a logging gap; from a supervisory perspective it is an unreconstructable onboarding decision.
Webhook and callback trust
Most verification providers deliver results asynchronously by webhook, and webhook handlers are consistently the weakest component in the pipeline. Findings we see regularly: signature verification implemented but not enforced when the header is absent; verification against a shared secret transmitted in the same request; replay accepted because no nonce or timestamp window is checked; and — most damaging — the handler trusting the status field in the payload without an independent read-back from the provider API.
An unauthenticated or forgeable webhook that sets a customer to verified is a complete bypass of the control the whole pipeline exists to implement. Test it directly, including the case where the signature header is simply omitted.
Fail-open behaviour
When a screening provider is unavailable, what happens? There are two defensible answers — block onboarding, or allow with a mandatory review queue — and one indefensible one, which is to log the error and continue. We find the indefensible option more often than either alternative, usually introduced during an incident when the provider outage was blocking legitimate customers and someone added a bypass that was never removed.
The same applies to sanctions screening in the transaction path. Fail-open there is not a technical debt item; it is a control that does not operate under exactly the conditions an attacker would choose to create.
Data flow beyond the pipeline
Verification data rarely stays where it was collected. It gets copied into the CRM so support can answer questions, into the data warehouse for analytics, into risk models, and into whatever spreadsheet somebody built for a regulatory return. Each copy inherits the sensitivity and loses the controls.
Trace the flow properly during assessment. The finding is usually not the pipeline itself but the third copy, in a system with a different access model, retained past the retention policy because deletion was implemented only in the primary store.
Provider credential handling
Integration credentials for identity and screening providers are high-value: they permit queries against the provider on the firm's account, and in some cases retrieval of historic results for any customer. Review where these credentials live, whether they are shared between environments, whether the non-production environment uses a sandbox tenant or the live one, and whether rotation has ever been exercised.
Audit trail completeness
The final and most consequential category. A supervisor asking why a specific customer was onboarded needs to reconstruct: what data was submitted, which checks ran, what each returned, who reviewed anything flagged, what decision was made and on what authority. If any element is missing the firm cannot answer, regardless of whether the decision was correct.
Assess the audit trail as a control with its own threat model. Who can write to it, who can delete from it, does it survive a database restore, and is it retained for the full regulatory period rather than the default log retention of the platform it happens to sit on? An audit trail that a privileged application account can rewrite is documentation, not evidence.
Where to start
If the pipeline has never been assessed, the highest-yield sequence is: webhook handler first, because a bypass there defeats everything downstream; then artefact retrieval authorisation; then failure-mode behaviour; then audit trail completeness. Those four cover the findings that turn a technical weakness into a regulatory one.
