Your CRM is a revenue tool. It is the wrong KYC system.

Your best sales tool is your worst compliance infrastructure

Regulated institutions spend months building KYC onboarding portals inside their CRM. They configure custom objects, bolt on document upload components, wire up third-party verification APIs through middleware, and dedicate engineering resources to maintaining it all. Then the compliance policy changes or a new entity type needs a different verification sequence. And the whole construction starts to crack.

The problem is not the implementation. The problem is the architecture. A CRM is a world-class tool for managing commercial relationships. It was never designed to be a system of record for compliance evidence.

Key takeaways

• A CRM organizes commercial events. Compliance requires a desired state. These are not just different data models, they are different architectural philosophies. A CRM asks: "what happened with this client?" Compliance asks: "is this client demonstrably compliant right now, and what evidence proves it?" Workflow systems are initially easier to build, but compound in complexity every time a requirement changes.

• Workflow-based systems break under compliance pressure. When a regulatory requirement changes, a CRM-based KYC setup requires development work to rebuild sequences. An evidence-based system recalculates affected cases automatically, without engineering involvement.
• Presenting a CRM to a regulator carries real, personal sanctions risk. Between October 2024 and December 2025, the AMF concluded 12 LCB-FT decisions totaling €5.815 million. In 100% of sanction decisions, directors were personally sanctioned. Two received permanent industry bans. The AMF does not just sanction process failures; it sanctions the absence of a system that makes compliance structurally demonstrable (Autorité des Marchés Financiers, LCB-FT Jurisprudence Guide by Ondorse, 2026).
• A CRM cannot manage periodic reviews or KYC monitoring. It has no native mechanism to trigger document refresh cycles, updated document requirements, re-screen clients against PPE lists, or flag stale dossiers by risk tier. The result is a portfolio that looks current in the CRM and is non-compliant in front of a regulator. This is the direct path to perpetual remediation campaigns and sanctions. 63% of ACPR grievances in 2023 targeted ongoing vigilance failures, not Day 1 processes.

• A CRM and Ondorse are not competing systems. They serve different functions in the same stack. The integration pattern is proven across multiple regulated institutions: the CRM triggers, Ondorse decides, the CRM receives the outcome.
• The right architecture is simple: the CRM owns the commercial relationship, Ondorse owns the compliance record. Each system does what it was built for. Neither compromises the other.

Why do compliance teams end up building KYC in their CRM in the first place?

The logic is understandable. Sales teams already live in Salesforce. Customer data is there. Opportunities and account records are there. When a new client signs, the obvious next step seems to be: trigger the KYC workflow from the same system that generated the deal.

The trap is that "obvious" and "correct" are not the same thing.

Salesforce is excellent at what it was built for: managing commercial relationships, tracking pipeline, storing interactions between a sales team and its customers. The data model reflects this. Everything revolves around Accounts, Contacts, Opportunities, and Cases tied to commercial outcomes.

Know Your Customer (KYC) and Know Your Business (KYB) compliance operates on a completely different ontology. The central object is not a customer. It is a risk assessment. The system needs to track:

• What evidence was collected, from which source, at what time
• What verification checks ran, in what sequence, with what result
• What risk score was calculated, on what parameters, with what override rationale
• What decision was made, by whom, under which policy version
• What events since have required re-assessment

None of this maps naturally onto Salesforce's data model. Teams work around it with custom objects, custom fields, and custom code. That is not a configuration. That is a bespoke compliance application built on top of CRM infrastructure that was not designed to support it.

What actually breaks when you build KYC in a CRM?

The failure modes follow a predictable sequence. They rarely appear all at once. They compound over time.

The root cause is architectural. A CRM records what happened. It has no native concept of what needs to happen next. Compliance, by contrast, is a continuous obligation to maintain a desired state: a structured, auditable record of who is compliant, with what evidence, as of right now. The gap between those two models is where regulatory exposure lives.

In practice, that gap opens in this order:

• Policy change paralysis. When a new internal policy or regulation requires an additional verification step, or a risk threshold changes, teams must open a Salesforce development ticket. Changes take weeks. Meanwhile, cases proceed under outdated rules and a remediation project on the backlog of customers is initiated.

• Regulatory audit exposure. Custom Salesforce objects do not constitute an immutable, regulator-readable audit trail. When an AMF or ACPR inspector asks how a risk decision was made and why, "we have a custom object in Salesforce" is not a defensible answer. The AMF has established a clear principle across its 2024-2025 jurisprudence corpus: an institution's Lutte Contre le Blanchiment et le Financement du Terrorisme (LCB-FT) procedure must be self-sufficient and cannot simply refer back to "the tool". The tool must support the procedure, not replace it.
• Fragmented provider management. Anti-Money Laundering (AML) screening, Identity Document Verification (IDV), company registry enrichment, Ultimate Beneficial Owner (UBO) graph resolution: each requires a separate integration. Salesforce becomes the middleware for services it was not built to orchestrate. Every API update from a provider breaks something in the chain.
• Periodic reviews fall through the cracks. This is the failure mode that directly opens the door to perpetual remediation cycles. Vigilance constante under Article L. 561-6 of the Code monétaire et financier requires ongoing monitoring, periodic risk re-classification, and document refresh throughout the entire client relationship. A CRM has no native mechanism to detect that a client's Kbis is now more than three months old, flag that a Personne Politiquement Exposée (PPE) screening has lapsed, or enforce a refresh cadence by risk tier. When that infrastructure is absent, the result is a portfolio of dossiers that look current in the CRM and are non-compliant in the eyes of the regulator. The AMF made this explicit in decision TRA-2025-05: an institution that relied on declarative questionnaires at entry for PPE identification, with no update during the relationship, was sanctioned. Knowing the client for a long time does not constitute diligence.
• AI falls on the wrong foundation. AI agents produce useful outputs only when the data context they operate on is structured correctly for the task. Compliance AI running on commercial CRM data produces commercial-context reasoning. It cannot surface the right risk signals because it is reading a sales record, not a risk record.

The consequence is a cycle that most institutions recognise only once they are already inside it: a one-time investment in onboarding KYC, followed by repeated remediation campaigns to bring the portfolio back into compliance, repeated indefinitely because the root cause was never fixed. The AMF has ruled on this scenario specifically: documents constituted or solicited after the regulator's inspection are taken as evidence of the original failure, not as remediation. The manquement is characterised; the remediation does not erase it. A system that was not designed to monitor cannot generate the triggers that would prevent remediation from becoming permanent.

Is this a Salesforce problem, or an architecture problem?

It is an architecture problem. Salesforce does exactly what it is supposed to do.

The mistake is asking it to do two things at once: manage the commercial relationship and hold the compliance record. These functions have different data requirements, different audit requirements, different update cadences, and different regulatory obligations.

The correct architecture separates them cleanly.

In this architecture, Salesforce does not disappear. It does its job better, because it no longer carries the compliance burden. It receives clean, structured outcomes from Ondorse and displays them to commercial teams in the context they need.

Does this mean ripping out Salesforce?

No. And this distinction matters.

The integration pattern that Ondorse has deployed with multiple regulated institutions works as follows:

1. A new client record is created in Salesforce (Account + Opportunity).
2. Salesforce triggers a KYC case creation in Ondorse via REST API, passing relevant commercial data.
3. Ondorse runs the full compliance lifecycle: data collection via white-label portal or headless API, verification checks against official registries and AML providers, risk scoring, analyst review, and decision.
4. Ondorse fires a webhook back to Salesforce with the compliance outcome: approved, pending, rejected, or requiring Enhanced Due Diligence (EDD).
5. Commercial teams see a compliance status field in Salesforce, updated in real time, without ever touching the underlying compliance infrastructure.

This is a bidirectional, event-driven integration over REST API and webhooks. It is documented, versioned, and replicable. It does not require Salesforce customization beyond a standard API connection.

The Salesforce team keeps its system. The compliance team gets a purpose-built platform. Neither compromises the other.

What does the wrong architecture cost in practice?

The numbers are concrete.

Every manual re-request loop caused by a misconfigured or inflexible Salesforce-based workflow adds time directly to the customer experience. In competitive B2B markets, slow onboarding is a conversion problem before it is a compliance problem.

The average time to onboard a business customer in banking is 28 days. A significant portion of that delay is administrative friction caused by disconnected systems, manual data re-entry, and email-based document chasing. None of this is inherent to compliance. It is inherent to using the wrong tool.

The AMF's 2024-2025 LCB-FT jurisprudence corpus puts a precise number on what happens when compliance infrastructure is inadequate. Between October 2024 and December 2025, the AMF rendered or concluded 12 decisions covering portfolio management companies and financial investment advisers. Total financial consequences: €5.815 million (€2.71M against legal entities, €3.1M against individual directors, personally). In 100% of the sanction decisions, directors were sanctioned at the individual level. Two received permanent industry bans (AMF, LCB-FT Jurisprudence Guide, 2025).

The deficiency rates found inside sampled client dossiers are not anomalies. In one decision (SAN-2025-09), 94% of sampled files had KYC and PPE identification gaps. In another (SAN-2025-13), 84% of sampled files were missing a valid proof of address. In SAN-2025-11, 73% of sampled files had no Politically Exposed Person (PPE) screening trace, no sanctions list check, and no asset-freeze search on record.

The pattern across every case is identical: the procedure existed. The tool was deployed. The dossiers were empty. Regulators do not just penalise what teams did wrong. They penalise the absence of a system that makes doing things right structurally enforceable.

Can an evidence-based system handle policy changes without development work?

This is the core architectural difference, and it is worth being precise about it.

A workflow-based system, which is what any CRM becomes when adapted for compliance, optimizes for sequences of steps. Step A must happen before Step B. If the compliance policy changes and Step B is no longer required, or a new Step C needs to be inserted between A and B, someone must modify the workflow. That requires development. It takes time. And until the fix is deployed, cases proceed under the old rules.

An evidence-based system works differently. Instead of encoding compliance as a fixed sequence of steps, it models compliance as a set of requirements that must be satisfied. Each case has a live dependency graph: a structured map of what evidence is required, what has been collected, and what gap remains. When a policy changes, only the requirement definition is updated. The system then re-evaluates every open case against the new requirements and surfaces the delta: the specific tasks, per case, that need to be completed, dropped, or re-run. This re-evaluation happens at query time, not at authoring time. No workflow needs to be rebuilt. No cases need to be manually reviewed to identify which ones are affected. The system resolves it.

Ondorse is built on this model. The reason this capability is rare is that it requires separating the compliance rule layer from the evidence layer from the execution layer (three distinct data models that most compliance tools, and all CRMs, conflate into a single workflow). When those layers are separate, compliance teams can update rules, thresholds, and document requirements directly in the platform, without developer involvement, and the change propagates immediately to every live case.

This matters not just for efficiency. It matters for regulatory defensibility. When a regulator asks whether a case processed after a policy update was handled under the new rules, the answer needs to be demonstrable, not approximate.

How does Ondorse integrate with the leading CRM, SalesForce, in practice?

The integration is a standard CRM pattern. It does not require rebuilding anything on either side.

The Ondorse integration documentation identifies five integration types ranging from zero-code to fully headless, with the CRM integration estimated at one to three weeks end to end.

The mechanics centre on three touchpoints:

The Salesforce data model is not modified beyond a small number of status fields. The compliance record, the full evidence trail, the risk scoring parameters, the audit log, and all provider outputs live exclusively in Ondorse. Salesforce receives a structured outcome, not a data dump.

For institutions that also operate a proprietary back-office or front-office platform alongside Salesforce, the integration extends naturally. In the architecture of a well established cross-border financial institution using Ondorse, Salesforce handles the classic CRM integration (case creation trigger, status feedback), while our customer's back-office connects independently to Ondorse via a separate in-app integration to post lifecycle events and trigger ongoing due diligence reviews. The two integrations run in parallel without conflict, because each system is reading from and writing to Ondorse through its own API surface.

The result in production: sales teams continue working in Salesforce without any workflow disruption. Compliance teams gain a dedicated platform where every dossier is structured, timestamped, and auditable. The institutions that have deployed this pattern report approximately a 50% reduction in onboarding time and the ability to absorb significant volume growth without adding compliance headcount.

Why the right question is not "can a CRM do KYC?" but "should it?"

Salesforce and other CRMs can do many things. Its platform is extensible, its AppExchange ecosystem is wide, and its development community is large. With enough custom code, it is possible to approximate a compliance workflow inside Salesforce.

The question is not whether it is possible. The question is what the total cost of that choice is, over time.

Every compliance policy update requires a development ticket. Every new verification provider requires a custom integration. Every regulator visit requires explaining why the system of record is a sales CRM. Every AI capability built on top of it inherits the wrong data context.

Compliance complexity does not decrease over time. It increases. An architecture that handles initial requirements but accumulates technical debt with every regulatory change is not a compliance architecture. It is a liability that compounds.

The right split is simple: Salesforce owns the commercial relationship. Ondorse owns the compliance record. They talk to each other over a clean API. Neither system carries the burden of the other.

Ondorse connects to Salesforce out of the box, with an integration pattern validated across regulated institutions including payment institutions, banks, Electronic Money Institutions (EMIs) and Asset Managers (AM). To see how the architecture applies to your stack, explore Ondorse's integration guide or speak with the team.