SfSkills Domains Docs GitHub

Home / architect / banking-lending-architecture

banking-lending-architecture

Architecture guidance for Salesforce FSC banking and Digital Lending: loan origination platform design, ResidentialLoanApplication data model, payment processing integration patterns, and account servicing workflow architecture. NOT for FSC Insurance policy, claims or underwriting architecture — use architect/insurance-cloud-architecture. NOT for the FSC data-model choice and Compliant Data Sharing design — use architect/fsc-architecture-patterns.

Open the skill folder on GitHub

Banking and Lending Architecture

This skill activates when an architect or senior practitioner needs to design a Salesforce FSC banking or lending solution — covering loan origination platform selection, the ResidentialLoanApplication data model, payment processing integration patterns, and account servicing architecture. It does NOT cover FSC Insurance Cloud, implementation-level OmniScript development, or generic CRM configuration.

Before Starting

Gather this context before working on anything in this domain:

Core Concepts

Digital Lending Platform

FSC Digital Lending is a pre-built loan origination platform requiring OmniStudio and the industriesdigitallending namespace. It provides OmniScript-driven loan intake, Integration Procedure hooks for credit bureau and income verification calls, and a FlexCard-based loan officer workspace. It is NOT a standalone set of standard objects — the full platform requires:

If any prerequisite is missing, the Digital Lending UI does not render and APIs return errors.

ResidentialLoanApplication Data Model

The ResidentialLoanApplication object anchors the FSC lending data model:

ObjectRole
LoanApplicantChild of ResidentialLoanApplication, linked to a Person Account. The loanApplicantAutoCreation flag controls automatic Account creation.
LoanApplicantAssetDeclared assets (real estate, vehicles, savings).
LoanApplicantLiabilityDeclared liabilities (mortgages, auto loans, credit cards).
LoanApplicantIncomeIncome sources.
LoanApplicantAddressAddress history.

This hierarchy is separate from FSC's Financial Account objects. Loan origination lives in ResidentialLoanApplication; serviced loans (post-close) are represented as FinancialAccount records (Liability type).

Async Payment Processing Pattern

Payment processing in banking workflows requires an async architecture:

  1. User initiates payment from Salesforce UI
  2. Integration Procedure makes outbound call to payment processor API
  3. IP returns a pending transaction reference to the UI immediately
  4. Payment processor sends confirmation callback via REST API or platform event
  5. Salesforce platform event trigger or Flow updates the payment record

This pattern handles payment processor latency, avoids governor limit violations, and provides retry capability for failed transactions.

Common Patterns

OmniScript-Driven Loan Origination with Integration Procedures

When to use: FSC Digital Lending is licensed and OmniStudio is provisioned.

How it works:

  1. OmniScript collects applicant data across multiple steps.
  2. Integration Procedures call credit bureaus (Experian, Equifax) and income verification (Plaid, Finicity) at decision gates.
  3. industriesdigitallending APIs evaluate eligibility and return a conditional approval.
  4. ResidentialLoanApplication and child objects are created upon submission.
  5. Loan officer FlexCard shows pipeline with real-time status from Integration Procedure polling.

Why not Flow/Apex: Digital Lending OmniScripts are pre-built and configurable for common loan products. Rebuilding in Flow requires creating the entire guided UX, integration hooks, and decisioning layer from scratch.

Async Payment Initiation

When to use: Any payment action in FSC — mortgage payment, ACH transfer, wire.

How it works:

  1. Integration Procedure calls payment processor API asynchronously.
  2. Returns pending transaction ID to the user immediately.
  3. Platform event or REST callback from processor updates payment status.
  4. Triggered automation on status update notifies borrower and updates loan record.

Why not synchronous callout: The 100-callout-per-transaction limit, variable payment processor response times (up to 10+ seconds), and transaction rollback behavior on timeout make synchronous callout architecturally unsound for payment workflows.

Decision Guidance

SituationRecommended ApproachReason
Loan origination with OmniStudio availableFSC Digital Lending + OmniScriptPre-built guided intake with Digital Lending data model
Loan origination without OmniStudioCustom Screen Flow + ResidentialLoanApplicationObject model available without Digital Lending platform
Payment initiationAsync Integration Procedure + platform event callbackAvoids callout limits and handles processor latency
Core banking data syncBatch Data Synchronization via Bulk API 2.0Handles large volumes; designed for banking batch patterns
Real-time payment status updatesRemote Call-In (processor calls SF REST API)External system pushes status to Salesforce
Credit bureau integrationIntegration Procedure + HTTP calloutDeclarative, governor-safe, auditable
  1. Prerequisites audit — Confirm OmniStudio provisioning, industriesdigitallending namespace availability, and required IndustriesSettings flags before committing to Digital Lending platform.
  2. Platform selection — Choose Digital Lending (full pre-built platform) or custom ResidentialLoanApplication (if OmniStudio unavailable). Document the choice and rationale.
  3. Data model design — Map all loan application data requirements to the ResidentialLoanApplication hierarchy. Design post-close representation as FinancialAccount (Liability type).
  4. Integration pattern design — Select pattern for each external system: async IP callout, batch Bulk API sync, or Remote Call-In.
  5. Payment architecture — Design all payment flows as async IP calls with platform event callbacks. Document the callback endpoint and security configuration.
  6. IndustriesSettings documentation — List all required flags and their values in the environment setup runbook.
  7. Review — Verify no synchronous Apex payment callouts, loanApplicantAutoCreation flag strategy is deliberate, and Digital Lending prerequisites are fully documented.

Review Checklist

Salesforce-Specific Gotchas

  1. OmniStudio is a hard prerequisite for Digital Lending — FSC Digital Lending requires OmniStudio provisioning. Orgs purchasing FSC without OmniStudio cannot use the Digital Lending guided origination experience. This dependency is frequently missed at project kickoff when license procurement does not include OmniStudio.
  2. loanApplicantAutoCreation defaults to off — Without this flag, creating a LoanApplicant via API or OmniScript does not auto-create the associated Person Account. Integration teams that bulk-load LoanApplicant records without enabling this flag produce orphan applicant records with no Account association.
  3. Payment callouts from Apex triggers violate the 100-callout limit — Any synchronous payment initiation pattern in a trigger context will fail when multiple records are processed simultaneously, leaving payment records in an inconsistent state. Async Integration Procedure with callback is the required pattern.

Output Artifacts

ArtifactDescription
Lending platform decision matrixComparison of Digital Lending vs custom ResidentialLoanApplication with OmniStudio prerequisite documented
ResidentialLoanApplication data modelHierarchy diagram covering loan applicant, financial details, and Account linkage
Payment integration architectureAsync payment flow diagram with platform event callback and retry pattern

Dependencies

Package files