KYC and client onboarding workflows on Dynamics 365

Know-your-customer onboarding is a workflow problem wrapped in a regulatory one. A relationship manager needs to collect identity and ownership documents, verify them, screen the client against sanctions and politically-exposed-person lists, rate the risk, get approval, and open the account — while producing an audit trail a regulator can read years later. Dynamics 365 is a good orchestration layer for this, and a bad choice for the pieces that need specialist engines. This guide covers the pattern that keeps those roles straight. For the sector overview see Dynamics 365 for financial services; for what Microsoft's industry cloud adds, Microsoft Cloud for Financial Services.

What Dynamics 365 does and does not do

It does: case-style workflow with stages and gates, task assignment, document collection and storage, integration with verification and screening services, approval routing, audit logging, and a single view of the client and everything gathered about them.

It does not: verify identity documents to a certified standard, screen against sanctions lists, score AML risk with a supervised model, or hold the account. Identity verification vendors, screening providers, transaction-monitoring platforms, and the core banking system do those. An onboarding design that has Dynamics 365 doing screening from a downloaded list is a design a regulator will dislike.

The onboarding case

Model each onboarding as a record — a case in Customer Service, or a dedicated onboarding table for institutions that want a clean schema — linked to the client (contact or account) and to the related parties: beneficial owners, directors, signatories, each a contact with a relationship record carrying their role and ownership percentage. Ownership structures for corporate clients are trees; the connection records and account hierarchies in Dataverse handle them, and the account hierarchies guide is relevant.

A business process flow encodes the stages: intake, document collection, verification, screening, risk assessment, approval, account opening, and complete. Each stage has required fields that act as gates — the flow cannot advance to screening without a verified identity document reference — and the stage history is part of the audit evidence. The business process flows guide covers the mechanics.

Requirements vary by client type and jurisdiction: a retail individual, a domestic private company, and an offshore trust need different documents. Model the document checklist as data — a requirement matrix by client type and risk tier — that generates the required document records on the case, rather than hard-coding it into the flow.

Collecting documents

Clients upload through a Power Pages portal authenticated with Entra External ID; the customer access guide covers the identity side. Documents land in SharePoint or Dataverse file columns against the requirement record. AI Builder document processing can extract fields from passports, utility bills, and incorporation documents to pre-fill the case and flag mismatches; the document automation guide covers it. Extraction is a productivity feature, not identity verification — the verification result comes from the vendor.

Retention matters: onboarding documents must be kept for the regulatory period after the relationship ends and then deleted. Set the retention policy on the storage location at design time, and make sure the file columns and SharePoint site are both covered; the Purview guide describes the labelling.

Screening and verification integration

Identity verification and sanctions or PEP screening are external calls with a result and a reference. The clean integration is a Power Automate flow or an Azure Function triggered when the case enters the relevant stage, calling the vendor's API, writing the result and the vendor's reference to the case, and creating a review task if the result is a potential match. Never store the full screening response if it contains list data the institution is not licensed to retain; store the outcome and the reference.

Match review is human work with a decision and a rationale, both recorded on the case. Rescreening happens at every review cycle and, for institutions with continuous monitoring from the vendor, on the vendor's alert — which arrives as an event that reopens the case or creates a review case.

Risk rating and approval

The risk rating combines client type, jurisdiction, products, ownership complexity, source of wealth, and screening results into a tier. Simple rating logic — a points table — lives comfortably in Dataverse as a calculated result or a small plug-in. Model-driven scoring belongs in the compliance platform and is written back as a tier. Whichever produces it, the tier drives the approval route: standard clients approved by the relationship manager's supervisor, high-risk by compliance, and some by a committee.

Approval is a four-eyes control: the approver cannot be the preparer, the approval is a record with the approver's identity and timestamp, and the case cannot advance without it. Power Automate approvals or the case's own approval stage with a security-role check both work; the point is that the evidence is a record, not an email.

Dataverse auditing must be enabled on the case, the client, the related parties, and the document requirement tables, with retention set to the regulatory horizon. The Dataverse auditing coverage describes the settings.

Periodic review

KYC is not once. Each client has a review date based on tier — annually for high risk, less often for standard — and a trigger event list: change of ownership, change of jurisdiction, a screening alert, unusual activity from monitoring. A scheduled flow creates review cases as dates fall due; integration events create them on triggers. The review case reuses the onboarding model with a lighter checklist. Institutions that build onboarding without periodic review build it twice.

Account opening

When approval completes, the account is opened in the core banking or portfolio system, not in Dynamics 365. The integration sends the approved client data, receives the account identifier, and closes the case. If the core system is the source for client static data thereafter, the CRM contact must be updated from it — the same system-of-record discipline that applies in every CRM-to-core integration.

Cloud for Financial Services

Microsoft's industry cloud provides a financial-services data model on Dataverse — customers, accounts, holdings, financial products — and unified-profile and onboarding components built on it. Adopt the data model early if the institution is likely to use more of the industry cloud; it saves inventing tables. Evaluate the onboarding components against the pattern above rather than assuming they replace it; they accelerate the case model and the profile, and still depend on the same external vendors for verification and screening.