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 implementation-level OmniScript development, FSC Insurance Cloud, or generic CRM data modeling.

Best use case

banking-lending-architecture is best used when you need a repeatable AI agent workflow instead of a one-off prompt.

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 implementation-level OmniScript development, FSC Insurance Cloud, or generic CRM data modeling.

Teams using banking-lending-architecture should expect a more consistent output, faster repeated execution, less prompt rewriting, better workflow continuity with your supporting tools.

When to use this skill

  • You want a reusable workflow that can be run more than once with consistent structure.
  • You already have the supporting tools or dependencies needed by this skill.

When not to use this skill

  • You only need a quick one-off answer and do not need a reusable workflow.
  • You cannot install or maintain the underlying files, dependencies, or repository context.

Installation

Claude Code / Cursor / Codex

$curl -o ~/.claude/skills/banking-lending-architecture/SKILL.md --create-dirs "https://raw.githubusercontent.com/PranavNagrecha/AwesomeSalesforceSkills/main/skills/architect/banking-lending-architecture/SKILL.md"

Manual Installation

  1. Download SKILL.md from GitHub
  2. Place it in .claude/skills/banking-lending-architecture/SKILL.md inside your project
  3. Restart your AI agent — it will auto-discover the skill

How banking-lending-architecture Compares

Feature / Agentbanking-lending-architectureStandard Approach
Platform SupportNot specifiedLimited / Varies
Context Awareness High Baseline
Installation ComplexityUnknownN/A

Frequently Asked Questions

What does this skill do?

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 implementation-level OmniScript development, FSC Insurance Cloud, or generic CRM data modeling.

Where can I find the source code?

You can find the source code on GitHub using the link provided at the top of the page.

SKILL.md Source

# 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:

- **Digital Lending requires OmniStudio** — FSC Digital Lending is built on OmniStudio (OmniScripts, FlexCards, Integration Procedures) and the `industriesdigitallending` Apex namespace. OmniStudio must be provisioned and active before Digital Lending workflows can function. This is the most commonly missed dependency at project kickoff.
- **IndustriesSettings flags** — `enableDigitalLending` and `loanApplicantAutoCreation` must be enabled in the IndustriesSettings metadata or Setup UI. Without `loanApplicantAutoCreation`, LoanApplicant records do not auto-create the associated Person Account.
- **Payment processing must be async** — Designing payment initiation as a synchronous Apex callout on record save violates the 100-callout-per-transaction limit. All payment calls must be async via Integration Procedures with platform event callbacks.
- **Core banking as system of record** — Most FSC banking implementations use an external core banking system (FIS, Fiserv, Temenos) as the servicing system of record. Salesforce is the engagement and origination layer. Design data flows accordingly.

---

## 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:

- OmniStudio license and provisioning
- `enableDigitalLending` IndustriesSettings flag enabled
- `industriesdigitallending` Apex namespace deployed
- Connected App configuration for external service integrations

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:

| Object | Role |
|---|---|
| LoanApplicant | Child of ResidentialLoanApplication, linked to a Person Account. The `loanApplicantAutoCreation` flag controls automatic Account creation. |
| LoanApplicantAsset | Declared assets (real estate, vehicles, savings). |
| LoanApplicantLiability | Declared liabilities (mortgages, auto loans, credit cards). |
| LoanApplicantIncome | Income sources. |
| LoanApplicantAddress | Address 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

| Situation | Recommended Approach | Reason |
|---|---|---|
| Loan origination with OmniStudio available | FSC Digital Lending + OmniScript | Pre-built guided intake with Digital Lending data model |
| Loan origination without OmniStudio | Custom Screen Flow + ResidentialLoanApplication | Object model available without Digital Lending platform |
| Payment initiation | Async Integration Procedure + platform event callback | Avoids callout limits and handles processor latency |
| Core banking data sync | Batch Data Synchronization via Bulk API 2.0 | Handles large volumes; designed for banking batch patterns |
| Real-time payment status updates | Remote Call-In (processor calls SF REST API) | External system pushes status to Salesforce |
| Credit bureau integration | Integration Procedure + HTTP callout | Declarative, governor-safe, auditable |

---

## Recommended Workflow

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

- [ ] OmniStudio confirmed available if Digital Lending platform is in scope
- [ ] `industriesdigitallending` namespace dependency documented
- [ ] `loanApplicantAutoCreation` IndustriesSettings flag status confirmed
- [ ] All payment flows use async Integration Procedure + callback pattern
- [ ] No synchronous Apex callouts for payments or credit checks
- [ ] ResidentialLoanApplication hierarchy correctly mapped to requirements
- [ ] Post-close loan servicing represented as FinancialAccount (not ResidentialLoanApplication)

---

## 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

| Artifact | Description |
|---|---|
| Lending platform decision matrix | Comparison of Digital Lending vs custom ResidentialLoanApplication with OmniStudio prerequisite documented |
| ResidentialLoanApplication data model | Hierarchy diagram covering loan applicant, financial details, and Account linkage |
| Payment integration architecture | Async payment flow diagram with platform event callback and retry pattern |

---

## Related Skills

- `fsc-architecture-patterns` — For broad FSC data model, sharing model, and integration strategy baseline
- `industries-data-model` — For cross-industry object model reference including FSC lending objects

Related Skills

fsc-architecture-patterns

8
from PranavNagrecha/AwesomeSalesforceSkills

Use when designing or reviewing a Financial Services Cloud (FSC) solution architecture covering data model selection, Compliant Data Sharing design, integration strategy, and compliance framework alignment. Triggers: 'should I use the managed-package FSC data model or the platform-native model', 'how do I design Compliant Data Sharing for cross-team visibility in FSC', 'FSC integration architecture with core banking', 'which data model does FSC use for households and financial accounts'. NOT for individual FSC feature configuration (use admin/household-model-configuration or admin/financial-account-setup), NOT for person account mechanics outside FSC context (use data/person-accounts), NOT for generic sharing-rule design without FSC compliance requirements (use data/external-user-data-sharing).

salesforce-files-architecture

8
from PranavNagrecha/AwesomeSalesforceSkills

Working with Salesforce Files at the data layer — `ContentVersion` (the binary content + version metadata), `ContentDocument` (the parent / shareable handle), `ContentDocumentLink` (the sharing / parent-record join), the 2 GB single-file size limit and the 10 MB feed-attached limit, the deprecated `Attachment` object, the `Document` object (Classic-only), and Files Connect for external file sources. Covers SOQL patterns to enumerate files attached to a record, Apex insert / link patterns, sharing implications of `ShareType` and `Visibility`, and the migration path from the legacy Attachment object. NOT for LWC file upload UI components (see lwc/lwc-file-upload-patterns), NOT for static-resource bundling (see lwc/static-resources).

nonprofit-data-architecture

8
from PranavNagrecha/AwesomeSalesforceSkills

Use this skill when designing or querying the NPSP data model — constituent 360, household accounts, giving history rollups, and program participation. Trigger keywords: NPSP data model, household account, constituent record, giving rollups, CRLP, program engagement, ServiceDelivery, npo02__ fields. NOT for standard data model design, Nonprofit Cloud (NPC) data model, FSC household groups, or platform data modeling outside the NPSP context.

wealth-management-architecture

8
from PranavNagrecha/AwesomeSalesforceSkills

Use this skill when designing or reviewing a Salesforce Financial Services Cloud (FSC) wealth management platform — covering advisor workspace configuration, client portal setup, portfolio data integration, Compliant Data Sharing, and FSC feature enablement decisions. NOT for investment product advice, financial planning calculations, or FSC Health Cloud configurations.

subscription-management-architecture

8
from PranavNagrecha/AwesomeSalesforceSkills

Use when designing or evaluating Salesforce CPQ subscription lifecycle architecture: amendment flow, renewal automation, co-termination design, or billing integration at the contract level. Trigger keywords: amendment architecture, renewal automation, co-termination design, subscription ledger, large-scale amendment, billing schedule, swap pattern, SBQQ__Subscription__c. NOT for billing setup, standard Salesforce contracts without CPQ, or Revenue Cloud advanced order management.

service-cloud-architecture

8
from PranavNagrecha/AwesomeSalesforceSkills

Use when designing a Service Cloud solution end-to-end: channel strategy (phone, email, chat, messaging, social), routing model (queue-based vs skills-based Omni-Channel), knowledge strategy, entitlement and SLA enforcement, Einstein Bot / Agentforce deflection, and integration points. Triggers: service cloud architecture, case routing design, omni-channel strategy, contact center design, channel strategy, knowledge deflection, service console architecture. NOT for individual feature configuration (use admin/case-management), NOT for Einstein Bot conversation design (use agentforce/einstein-bot-architecture), NOT for telephony CTI implementation details.

security-architecture-review

8
from PranavNagrecha/AwesomeSalesforceSkills

Use when conducting a dedicated security architecture review of a Salesforce org — assessing sharing model completeness, FLS/CRUD enforcement, Apex security patterns, exposed API surface, Connected App policies, and Shield readiness. Produces a structured findings report with severity ratings (Critical/High/Medium/Low) and a 20+ point review checklist. Triggers: security architecture review, org security posture, sharing model audit, FLS coverage review, Connected App security, Shield assessment, org security health deep-dive, HIPAA or PCI security controls Salesforce. NOT for implementing security fixes (use security/* skills). NOT for the Salesforce Security Health Check UI (use security-health-check skill). NOT for a full WAF review across all pillars (use well-architected-review).

salesforce-shield-architecture

8
from PranavNagrecha/AwesomeSalesforceSkills

Salesforce Shield as an architectural choice — Platform Encryption + Event Monitoring + Field Audit Trail as three SEPARATELY-LICENSED components, none of which ship in any standard edition. Covers BYOK vs Cache-Only Key Service (CCKM) tradeoffs, probabilistic vs deterministic encryption schemes, the field-type encryption blocklist (Formula, Roll-Up Summary, indexed External ID), Field Audit Trail's 10-year retention model, and why every Shield design starts with a license confirmation. NOT for individual feature setup steps (see security/platform-encryption, security/event-monitoring, security/field-audit-trail), NOT for compliance certification mapping (HIPAA / FedRAMP / PCI specifics).

sales-cloud-architecture

8
from PranavNagrecha/AwesomeSalesforceSkills

Use when designing or reviewing a Sales Cloud solution architecture covering process automation strategy, integration points, data model decisions, and scalability planning. Triggers: 'design a Sales Cloud architecture for enterprise org', 'Sales Cloud data model and automation strategy', 'how to architect Sales Cloud for high-volume pipeline management'. NOT for individual feature configuration (use admin/opportunity-management or admin/lead-management), NOT for CPQ-specific decisions (use architect/cpq-vs-standard-products-decision), NOT for integration implementation details (use architect/sales-cloud-integration-patterns).

revenue-cloud-architecture

8
from PranavNagrecha/AwesomeSalesforceSkills

Architecting on Salesforce Revenue Cloud (Revenue Lifecycle Management — RLM, the successor to CPQ-Plus + Billing). Covers the five RLM domains (Product Catalog & Pricing, Transaction Management, Contract Lifecycle Management, Order-to-Cash, Billing), the canonical data model (Product2 / PricebookEntry / Quote / Order / OrderItem / Contract / Asset / BillingSchedule / Invoice / LegalEntity), multi-entity scoping via LegalEntity, the RLM ↔ ERP integration patterns (CDC + MuleSoft preferred over point-to-point trigger callouts), and the disambiguation between native RLM and the legacy `blng__` Salesforce Billing managed package and `SBQQ__` CPQ classic. NOT for declarative CPQ classic config (see omnistudio/cpq-classic-config), NOT for Subscription Management billing patterns predating RLM (see architect/cpq-architecture-patterns).

payer-vs-provider-architecture

8
from PranavNagrecha/AwesomeSalesforceSkills

Use this skill when designing or evaluating a Health Cloud implementation to determine whether the org serves a payer (health insurer), a provider (care delivery organization), or both — and to derive the correct object model, PSL matrix, and feature activation accordingly. Triggers: 'should we use MemberPlan or ClinicalEncounter', 'payer vs provider Health Cloud', 'which Health Cloud objects does an insurer use', 'setting up a Health Cloud org for a hospital vs a health plan', 'Provider Relationship Management vs clinical provider'. NOT for individual feature implementation within an already-classified payer or provider org, and NOT for Salesforce Health Cloud implementations that are clearly a single deployment type with no cross-sector ambiguity.

order-management-architecture

8
from PranavNagrecha/AwesomeSalesforceSkills

Use when designing or reviewing a Salesforce Order Management (OMS) solution architecture: fulfillment workflow strategy, split-order routing design, Omnichannel Inventory (OCI) integration, returns process architecture, and multi-location inventory management decisions. Trigger keywords: OMS architecture, split orders, fulfillment routing, OCI, order routing strategy, returns architecture, fulfillment location design. NOT for individual order setup or day-to-day OMS administration (use admin/commerce-order-management), NOT for storefront or checkout flow design, NOT for CPQ quote-to-order workflows.