Building Zero-Trust Data Sync for Financial Services

The Problem

Large financial services firm. $12B AUM. Three divisions:

• Wealth Management: High-net-worth individual clients, portfolio management
• Investment Banking: Corporate clients, M&A advisory, capital markets
• Retail Banking: Consumer checking/savings, mortgages, credit cards

Each division: separate Salesforce org. Why? Regulatory compliance (Chinese walls between investment banking and wealth management), different data models, acquired via M&A over 10 years.

The request from their COO:

"We have customers who use multiple divisions. Wealth client also has a mortgage. Corporate banking client's executives are wealth clients. We can't see this. Sales reps call the same person twice. It's embarrassing. We need unified customer view—but we can't violate Chinese walls or mix PII across divisions."

Translation: bidirectional sync with selective field visibility and compliance enforcement.

This is zero-trust data sync.

Zero-Trust Principles for Multi-Org Sync

Traditional sync assumes trust. Source org says "here's data," target org accepts it.

Zero-trust sync assumes:

• No implicit trust: Just because Division A has data doesn't mean Division B should see it
• Least privilege: Sync only fields that are explicitly approved for cross-division visibility
• Explicit authorization: Every sync requires documented approval (who authorized, when, why)
• Complete audit trail: Every field sync logged with timestamp, user, source, destination
• Field-level masking: Sensitive fields masked or redacted based on target org's permissions

Architecture: The Sync_Request__c Pattern

We implemented a request-based sync model instead of automatic sync.

How It Works

Step 1: User initiates sync request

Wealth Management rep sees Account "Acme Corp" exists in Investment Banking org. Wants to sync that data.

Instead of automatic sync, rep creates a Sync_Request__c record:

• Source_Org__c: "Investment-Banking-PROD"
• Target_Org__c: "Wealth-Management-PROD"
• Object_Type__c: "Account"
• Source_Record_ID__c: Global_ID of Account in IB org
• Requested_Fields__c: "Name, BillingAddress, Industry, Phone"
• Business_Justification__c: "Client relationship overlap—need unified view"

Step 2: Compliance review

Sync_Request__c triggers approval workflow:

• Compliance officer reviews request
• Verifies no Chinese wall violation (investment banking material non-public info can't go to wealth)
• Approves or rejects with reason

Step 3: Automated sync execution

Once approved, Platform Event triggers sync:

• Extract approved fields from source org
• Apply field-level masking (see below)
• Upsert into target org using Global_ID__c
• Log sync in Sync_Audit_Trail__c

Step 4: Ongoing sync

After initial approval, changes to approved fields auto-sync. New field requests require new approval.

Field-Level Masking Rules

Not all fields sync equally. Some need masking based on target org's classification.

Field Classification Levels

Level 1: Public (syncs unmasked to all orgs)

• Account.Name
• Account.Industry
• Account.Website

Level 2: Internal (syncs to same division only)

• Account.AnnualRevenue
• Contact.Email
• Contact.Phone

Level 3: Restricted (syncs with masking or not at all)

• Account.Credit_Rating__c → masked as "REDACTED" unless target has approval
• Contact.SSN__c → never syncs (PII protection)
• Opportunity.Deal_Terms__c → masked unless compliance approves (MNPI protection)

Implementation: Custom Metadata for Field Classification

We used Custom Metadata Types to store field-level sync policies:

Field_Sync_Policy__mdt

• Object_Name__c: "Account"
• Field_Name__c: "Credit_Rating__c"
• Classification_Level__c: "Restricted"
• Masking_Strategy__c: "Redact" | "Hash" | "Partial" | "None"
• Allowed_Target_Orgs__c: Comma-separated list of orgs allowed to see unmasked

At sync time, Apex checks classification:

if (fieldPolicy.Classification_Level__c == 'Restricted') {
    if (!fieldPolicy.Allowed_Target_Orgs__c.contains(targetOrgId)) {
        fieldValue = maskField(fieldValue, fieldPolicy.Masking_Strategy__c);
    }
}

The Sync Architecture

Components

1. Sync_Request__c (Custom Object)

Stores all sync requests with approval status, business justification, audit trail.

2. Sync_Config__c (Custom Object)

Defines which objects sync between which orgs, conflict resolution strategy, field mappings.

3. Sync_Audit_Trail__c (Custom Object)

Immutable log of every sync operation. Required fields:

• Timestamp, Source Org, Target Org, Object Type, Record ID
• Fields Synced, Masked Fields, User Who Initiated
• Approval Reference (links to Sync_Request__c)

4. Platform Events

Real-time sync trigger mechanism. When approved field changes in source org, Platform Event publishes to all target orgs.

5. Apex Sync Engine

Handles field extraction, masking, upsert, conflict resolution, error handling.

Data Flow

1. Investment Banking org: Account updated (Annual Revenue changes)
2. After Update trigger fires, checks if field is in approved sync list
3. If yes, publishes Account_Sync_Event__e with field changes
4. Wealth Management org receives event
5. Event trigger invokes Apex sync engine
6. Sync engine checks field policies, applies masking
7. Upserts Account in Wealth org (using Global_ID__c)
8. Logs sync in Sync_Audit_Trail__c

Conflict Resolution for Bidirectional Sync

When both orgs can update the same Account, conflicts happen.

Conflict Scenario

9:00 AM: Investment Banking updates Account.BillingCity = "New York"
9:01 AM: Wealth Management updates Account.BillingCity = "San Francisco"
9:02 AM: Which value wins?

Conflict Resolution Strategies

1. Last Write Wins (LWW)

Most recent update wins. Simple, but data loss risk if updates are seconds apart.

2. Source of Truth Wins

Designate one org as authoritative for specific fields. Investment Banking owns BillingAddress, Wealth owns Phone.

3. Manual Review

On conflict, create Sync_Conflict__c record for human review. Slow, but necessary for high-stakes data.

4. Field-Level Merge

If different fields updated, merge both changes. If same field updated, escalate to manual review.

Implementation: The Conflict_Resolution__c Object

We implemented strategy #4 (field-level merge with manual escalation).

When conflict detected:

1. Sync engine compares field-level timestamps
2. If different fields changed, apply both updates
3. If same field changed within 60-second window, create Conflict_Resolution__c record
4. Assign to data steward for resolution
5. Steward selects correct value, sync engine propagates to all orgs

Compliance and Audit Requirements

Financial services firms face strict data governance requirements.

Requirements We Had to Meet

1. Complete Data Lineage

• Where did this field value come from?
• When was it synced?
• Who authorized the sync?
• What was the business justification?

2. Immutable Audit Trail

• Cannot delete or modify audit records
• Implemented via custom permission set (no Delete access on Sync_Audit_Trail__c)
• Validation rule prevents modification after 24 hours

3. Chinese Wall Enforcement

• Investment Banking material non-public info cannot sync to Wealth
• Implemented via field classification + compliance approval workflow
• Attempted violations logged and escalated to compliance team

4. PII Protection

• Social Security Numbers, account numbers, dates of birth never sync
• Email and phone sync only with explicit approval
• Implemented via Field_Sync_Policy__mdt with hard blocks

5. Retention and Archival

• Audit trail retained for 7 years (SEC/FINRA requirement)
• Quarterly archive to S3 (immutable storage)
• Automated job purges data from Salesforce after 2 years, retains in archive

Real Results

Timeline: 6 months (architecture design, development, compliance review, UAT, rollout)

Scope:

• 3 orgs syncing bidirectionally
• Account, Contact, Opportunity objects
• 47 fields with approved sync policies
• 1,200 users across all divisions

Volume (first 6 months of operation):

• 4,200 sync requests submitted
• 3,800 approved (90% approval rate)
• 400 rejected (Chinese wall violations or insufficient justification)
• 780,000 record syncs executed
• 12 conflicts escalated to manual review (99.998% auto-resolution rate)

Business Impact:

• Duplicate customer outreach reduced by 73%
• Cross-division referrals increased 40% (wealth clients referred to IB, vice versa)
• Compliance audit completed with zero findings (first time in 5 years)

Their Chief Compliance Officer: "This is the first multi-org sync I've seen that actually respects Chinese walls. The audit trail is better than anything we've had before. We can prove to regulators exactly what data moved, when, and why."

Lessons Learned

1. Compliance Must Drive Design, Not Be Retrofitted

We started with compliance requirements (Chinese walls, PII protection, audit trails) and built architecture around them. Trying to add compliance to existing sync would have failed.

2. Request-Based Sync Reduces Risk

Automatic sync is faster, but request-based sync with approval workflow ensures every data movement is intentional and authorized. Worth the extra workflow overhead.

3. Field-Level Policies Are Non-Negotiable

Object-level sync is too coarse-grained. Need field-level control to enforce least privilege and minimize exposure.

4. Audit Trail Must Be Immutable

Don't rely on Salesforce Field History (limited retention, can be disabled). Build custom audit trail with strict permissions and archival strategy.

5. Conflicts Are Rare, But Escalation Path Is Critical

In 6 months, only 12 conflicts required manual review. But those 12 involved high-stakes data. Having a defined escalation process with data stewardship prevented data loss.

When to Use Zero-Trust Sync

Use zero-trust patterns if:

• You operate in a regulated industry (finance, healthcare, government)
• You have legal separation requirements (Chinese walls, data residency)
• You need complete audit trails for compliance
• Data has varying sensitivity levels (some fields public, some restricted)
• Your compliance team needs approval workflow before data moves

Standard sync is fine if:

• All orgs trust each other completely
• No regulatory restrictions on data sharing
• All users have same data access privileges
• Audit requirements are minimal

The Bottom Line

Multi-org sync in regulated industries requires zero-trust architecture.

Core patterns:

• Request-based sync with approval workflow
• Field-level classification and masking
• Immutable audit trails
• Conflict resolution with manual escalation
• Defense in depth (multiple layers of enforcement)

It's more complex than standard sync. But for financial services, healthcare, or any regulated industry, it's the only way to sync data while maintaining compliance.

Trust nothing. Verify everything. Audit always.