Know Your Customer (KYC) and Anti-Money-Laundering (AML) compliance are non-negotiable for any bank. Failure to comply produces multi-million-dollar fines, the loss of correspondent banking relationships, and management dismissals. Every regulator in the world publishes detailed rules. Every bank implements them with some combination of policy, process, technology, and human review.
Financial Services Cloud (FSC) is part of the technology layer for the implementation. It is not the whole answer. FSC ships the data shape that supports KYC and AML; the implementation team owns the rules; the screening services own the lookups. Knowing which layer owns what is half the design.
The KYC data shape
FSC's KYC support consists of standard fields and standard objects:
KYC fields on Person Account. A small set of standard fields capture the KYC outcomes. KYC Status (Not Started, In Progress, Complete, Expired). KYC Last Reviewed Date. KYC Next Review Date. Customer Risk Rating (Low, Medium, High, Critical).
Document Checklist. The list of identity and supporting documents required for the customer's KYC tier. The same Document Checklist object that mortgage origination uses, repurposed for onboarding KYC.
Identification Document. A standard FSC object that records each identity document the customer has provided. Document type, issuing jurisdiction, expiry date, verification status.
Compliance Review. A standard object that captures each periodic KYC review event, with the reviewer, the date, the outcome, and any escalations.
The shape is fit for purpose. The actual rules (what documents are required for each customer type, when reviews happen, how risk is calculated) live in configuration on top of the shape.
The KYC onboarding workflow
The standard new-customer KYC workflow runs as an Action Plan:
- Capture customer identification documents.
- Verify documents against issuing-authority records where available.
- Capture customer self-declared information: occupation, source of funds, expected account use.
- Run identity verification against external data sources.
- Run sanctions screening.
- Run politically-exposed-person (PEP) screening.
- Run adverse-media screening.
- Calculate the initial Customer Risk Rating.
- Trigger enhanced due diligence (EDD) for high-risk outcomes.
- Compliance review and approval.
- Mark KYC Status Complete on the Person Account.
The Action Plan instance becomes the audit trail. Each step has an owner, a deadline, a completion timestamp. Stalled steps surface in the compliance team's queue. Completed plans get archived but remain queryable for audit.
The orchestration is FSC's contribution. The rules (what is sanctions screening, who counts as a PEP, what triggers EDD) live in the screening services and in the compliance team's policies. The integration weaves them together.
Customer Risk Rating
The Customer Risk Rating field on Person Account is the operational anchor for most ongoing AML monitoring. Rating drives review frequency, transaction monitoring thresholds, and EDD requirements.
Standard ratings:
- Low. Annual review. Standard transaction monitoring. No EDD.
- Medium. Annual review with enhanced data collection. Tighter transaction monitoring. EDD on adverse signals.
- High. Semi-annual review. Intensive transaction monitoring. EDD at onboarding and at each review.
- Critical. Quarterly review. Real-time transaction monitoring. Standing EDD.
The rating is calculated from multiple inputs:
- Customer attributes: occupation, source of wealth, geographic exposure.
- Account attributes: product types, expected transaction volumes.
- Relationship attributes: PEP status of self or close associates, beneficial-ownership complexity.
- Screening outcomes: any sanctions hit, any adverse media.
The calculation lives in an Apex class or a Flow that runs at onboarding and at each review event. The output writes to the Customer Risk Rating field.
Sanctions and PEP screening
Sanctions and PEP screening run against external services. The integration pattern is fairly standard:
At onboarding. The customer's identity data gets submitted to the screening service. The service returns either a clean result or a list of potential matches. Each potential match becomes a Screening Result record in FSC. A compliance analyst reviews and either dismisses or confirms each match.
On change. When customer data changes (new name, new address, new beneficial owner), screening reruns. The integration is event-driven on the relevant fields.
Periodic refresh. Screening services update their data daily or weekly. The integration runs periodic batch jobs that re-screen the entire customer base against updated lists. New matches trigger Screening Result records and Compliance Review tasks.
The screening service is the source of truth for sanctions and PEP data. FSC stores the outcomes and orchestrates the review. Treating it the other way around (trying to maintain sanctions lists inside FSC) is a maintenance burden that no bank should accept.
AML transaction monitoring
Transaction monitoring is the ongoing AML responsibility. The bank watches transaction patterns for anomalies that may indicate money laundering: structured deposits below reporting thresholds, rapid in-and-out fund movement, unexpected large international transfers, patterns inconsistent with the customer's risk profile.
The transaction monitoring engine usually lives outside FSC. Specialised AML systems (NICE Actimize, SAS AML, Oracle FCCM) hold the rules engine, the historical transaction store, and the analyst-investigation workspace. FSC integrates with the AML system for two purposes:
Customer-side context. When the AML system flags a transaction, the analyst needs customer context. The integration surfaces the customer's KYC status, risk rating, recent Life Events, and relationship structure inside the AML investigation workspace.
Outcome propagation. When the AML system closes a flagged case with an outcome (false positive, true positive, suspicious activity report filed), the outcome propagates back to FSC for inclusion in the customer record and any subsequent risk-rating recalculation.
The two systems share the customer; each owns its domain.
Periodic review
KYC is not a one-time event. Customers' lives change; their risk profiles change. Regulations require periodic review at frequencies tied to the customer risk rating.
The Action Plan for periodic review is shorter than onboarding but follows the same shape:
- Notify the customer that a review is due.
- Re-capture self-declared information where it has changed.
- Re-screen against sanctions and PEP lists.
- Re-calculate the Customer Risk Rating.
- Compliance review and approval.
- Update the Person Account KYC Last Reviewed and KYC Next Review fields.
Reviews that flag changes (new PEP exposure, jurisdictional risk increase, adverse media) escalate to enhanced due diligence. Reviews that do not flag changes complete and roll forward the next-review date.
The audit-trail expectation
Regulators expect a defined audit trail for every KYC and AML decision. The FSC implementation supports this through:
Action Plan history. Every KYC and review plan instance is retained with the full task-completion history.
Screening Result records. Every screening hit and analyst decision is retained.
Compliance Review records. Every periodic review and its outcome is retained.
Field history tracking. The KYC Status, Customer Risk Rating, and related fields have field history tracking enabled to capture every change with timestamp and user.
The retention period typically follows the bank's broader record retention policy (commonly 7 years or more). Storage cost is non-trivial but unavoidable. The audit trail must survive personnel changes, system migrations, and external audits.
Common implementation mistakes
Three patterns Sapota has seen produce regulatory findings on FSC AML implementations:
Customer Risk Rating calculation that is too simple. A rating based only on customer-self-declared occupation undercounts risk. The rating must combine multiple signals: occupation, geography, product, transaction patterns, beneficial-ownership complexity, screening outcomes. Single-factor ratings consistently get flagged by regulators.
Periodic review that drifts. The KYC Next Review Date is set at onboarding and never refreshed. By year three, many customers are overdue for review. The fix is automated review scheduling tied to risk rating, with management reporting on overdue reviews.
Audit trail with gaps. Some KYC actions happen outside Salesforce (in email, in spreadsheets, in conversations). The audit trail captures only the FSC-recorded actions. Regulators investigating an incident find the gap.
Each mistake is avoidable with deliberate design at implementation. Each becomes expensive to remediate after the fact.
Designing the KYC and AML workflow on FSC? Sapota's Salesforce team, certified on Financial Services Cloud Accredited Professional (AP-208), runs KYC architecture, AML integration design, and audit-trail validation on every FSC engagement. Get in touch ->
See our Salesforce service page for the team.
