When enhanced due diligence applies
Enhanced due diligence is customer due diligence with the depth turned up, applied when a customer presents higher risk than the standard profile. The trick is knowing exactly when to escalate, so build the triggers into the workflow instead of leaving them to an analyst's instinct.
The common triggers are worth stating plainly:
-
PEP status, whether the customer is a politically exposed person or closely associated with one
-
A connection to a high-risk jurisdiction
-
A complex or opaque corporate structure, or expected activity that doesn't fit the customer's profile
When a trigger fires, enhanced due diligence demands source-of-funds and source-of-wealth documentation, which means proving where a specific deposit came from and how the customer accumulated their wealth over time.
Governance drives most enhanced due diligence failures. The information existed. The escalation didn't happen. Deutsche Bank's $186 million penalty cited persistent control deficiencies and poor customer due diligence, the kind of gap where a risk was visible but never rose to anyone empowered to act on it. That's why senior management approval of every high-risk relationship has to be a documented, mandatory step in the workflow, with the approver and the timestamp captured. A high-risk customer needs a documented name attached to the sign-off for enhanced due diligence to exist.
Ongoing monitoring and review triggers
The KYC know your customer process continues after the account opens. The customer record you built at onboarding starts decaying the moment it's filed, because people move and companies restructure while clean profiles pick up adverse media. Keeping the record current for the life of the relationship is the third pillar, and it needs two modes of review planned in advance.
The first mode is the scheduled periodic review, tied to the risk tier you set earlier. High-risk customers are reviewed more often than low-risk ones, which is the whole reason the risk rating fed forward. The second mode is event-driven, where a specific change forces a review outside the schedule.
Build these triggers explicitly:
-
A change of director or beneficial owner
-
A move into a new jurisdiction or a spike in transaction activity
-
An adverse media hit or a fresh sanctions match on rescreening
Monitoring frequency follows the risk rating for each customer. That's what regulators mean by a risk-based approach, and it's also how you avoid burning your team's hours reviewing low-risk salaried customers at the same cadence as a high-risk corporate. TD Bank's $3.1 billion resolution traced in large part to transaction monitoring that didn't keep pace with the activity flowing through it, a reminder that monitoring which exists on paper but doesn't fire in practice is worth nothing.
When a trigger fires, it feeds back into the same workflow. The customer re-enters the customer due diligence and screening steps, with an owner assigned and the evidence attached to the existing record. One workflow runs on a loop for as long as the customer stays.
Building the audit trail and controls
When an examiner arrives, they want to see one thing: the story of each customer, told through documentation. Why this customer was onboarded and who approved it, with the checks and timing clear. If you can produce that in minutes with the evidence attached, the review is short. If you're reconstructing it from memory and email threads, it isn't.
Record-keeping expectations for KYC know your customer are concrete. FATF Recommendation 11 requires records to be held for at least five years after the business relationship ends, and jurisdictions extend that. Belgium requires KYC records for 10 years after a relationship closes, so your retention rules have to reflect each jurisdiction where you operate. The value sits in an immutable trail that captures each checklist step and the evidence attached, with the owner tied to the record, so the record can't be quietly edited after the fact.
Three internal controls turn a good checklist into a defensible process. Maker-checker approvals mean the person who completes a step isn't the one who signs it off. Documented escalation paths make sure a high-risk finding reaches someone empowered to act. And version-controlled procedures let you show an examiner what your policy says today and what it said when a given customer was onboarded. That last point matters more than it sounds, because regulators assess whether decisions were reasonable and supported by evidence at the time they were made. This layer lets you stand behind the checklist.
Turning the checklist into a workflow
A KYC checklist template is a good start and a poor operating model. The shift you're after is from a static document to a live, standardized onboarding workflow your whole team runs the same way every time. That move is practical, and it happens in a sequence.
Start by assigning an owner to each step, so accountability is fixed before anything is automated. Then digitize the data and document capture so the required fields block progression and the evidence attaches to the record automatically. From there, wire the workflow into your onboarding and monitoring systems, with the core banking connection carrying the customer record across them instead of being re-keyed at each stage. Begin with your low-risk individual profiles and prove the process before you scale it to the complex corporate paths. Given that nearly half of banks report losing clients to slow or inefficient onboarding, the connected version pays for itself in retained business as much as in passed audits.
This is where a platform earns its place. Doocat builds banking infrastructure for banks and microfinance institutions, with digital KYC and document capture across every service, while multi-step approval chains and tamper-evident event logging express the audit trail and maker-checker control in software. If you're ready to convert the checklist in this guide into your own connected onboarding workflow, book a call with the Doocat team to map your KYC Know Your Customer process onto a system built to run it.