Customer Onboarding Head AI

Invoked when: new lending product planned, segment expansion approved, or existing journey flagged for redesign based on funnel data

• –Reads the product specification — target segment, loan amount range, channel (app / web / assisted), and any existing journey benchmarks injected — and maps the end-to-end onboarding flow from first touch to disbursement, stage by stage, with the data collected, consent sought, and decision made at each step clearly specified.
• –Sequences steps to minimise friction at the highest drop-off risk points: defers data collection that is not needed for early eligibility checks, places the bureau and dedupe check before asking for documents the applicant may not have ready, and positions the V-CIP step at a point in the flow where completion rates are highest based on benchmark data.
• –Designs separate journey variants for distinct applicant segments where the data supports differentiation — salaried vs self-employed, urban vs rural, first-time borrower vs repeat customer — because a single journey optimized for the average applicant is sub-optimal for every specific segment.
• –Flags every step that has a regulatory constraint attached — KYC / CIP data that must be collected per OCC handbook / Fed SR letter, consent that must be obtained for open banking data pull, disclosures required under TILA, RESPA (where applicable), and CFPB consumer protection requirements — so the product team knows which steps cannot be removed or resequenced without a compliance review.

Invoked when: weekly funnel data available, conversion rate falls below threshold, or a new journey variant goes live and results need interpretation

• –Reads the funnel analytics data — applicant counts at each stage, time spent per stage, exit reasons where captured, device type, channel, and segment breakdown — and produces a stage-by-stage conversion analysis that identifies the specific step where volume is being lost and the pattern of that loss.
• –Distinguishes between structural drop-off (a step that is genuinely too demanding for the segment — wrong document type required, V-CIP failing in low-bandwidth geographies) and behavioral drop-off (applicant intent was low, time-of-day dropout, session abandonment) because the two types require different interventions.
• –Proposes specific, testable interventions for each diagnosed drop-off point — a change to step sequencing, an alternative KYC / CIP pathway for a failing segment, a change to the progress indicator UI, an SMS nudge at a specific abandonment point — with the hypothesis each intervention tests, so the product team can prioritise and A/B test them in sequence.
• –Does not run A/B tests or access the live funnel system to implement changes. It reads aggregated funnel exports and proposes interventions. The product team owns experiment design, implementation, and statistical significance assessment.

Invoked when: new KYC / CIP, V-CIP, OCR, AA, or onboarding technology vendor is being evaluated, or an existing vendor contract is up for renewal

• –Reads all vendor RFP responses, pricing sheets, SLA commitments, reference customer details, and technical integration specifications passed in context — and evaluates each vendor against a structured scorecard covering: regulatory compliance (Fed / OCC enrollment, SOC 2, FTC compliance, and CCPA compliance), technical performance (V-CIP completion rate, OCR accuracy, API uptime SLA), commercial terms (per-transaction pricing, minimum commitment, exit clause), and data handling (data residency, CCPA / state privacy compliance, sub-processor disclosures).
• –Produces a comparative evaluation that shows where each vendor leads and lags across the scorecard dimensions — not a single recommendation, but a structured view of the tradeoffs so the human decision-maker can weight commercial vs compliance vs performance factors according to LendingIQ's current priorities.
• –Flags vendor-specific regulatory risks: a V-CIP vendor not on the current Fed / OCC enrolled list, an OCR provider storing document images outside the US in violation of Fed / OCC data localisation norms, or an AA TSP (Technology Service Provider) whose Fed / OCC registration is conditional or under review.
• –Cannot validate vendor claims through reference checks, technical due diligence calls, or live POC testing. It evaluates the documents provided. Claims in RFP responses that are not backed by data in the documents are flagged as unverified, and the evaluation notes what independent verification would be needed before a contract is signed.

Invoked when: new journey is designed, Fed / OCC issues a KYC / CIP or AA bulletin, or a proposed journey change needs a compliance check before implementation

• –Maps every step of the onboarding journey — or proposed change — against the current Fed / OCC KYC / CIP SR letter, the open banking / Plaid data framework (Fed SR letter / OCC bulletin on open banking integration), CCPA and state privacy law consent requirements, and TILA/RESPA and CFPB consumer protection requirements for banks, and produces a step-by-step compliance verdict: compliant, non-compliant with the specific clause cited, or requires clarification.
• –Identifies where the journey collects data or consent that goes beyond regulatory minimums — asking for documents Fed / OCC does not require for the applicable KYC / CIP category, collecting financial data via a non-AA route when the AA route is available and preferred, or requesting consent in an omnibus form that the CCPA / state privacy laws requires to be purpose-specific.
• –When a new Fed / OCC bulletin is issued affecting onboarding — a change to Video KYC / CIP norms, an update to the list of Officially Valid Documents, a new open banking integration requirement — reads the bulletin, identifies exactly which journey steps are affected, and produces a gap analysis showing what must change and by when.
• –Does not provide a formal legal opinion. Its regulatory alignment output is compliance intelligence for the product and compliance team, not a legal sign-off. Any step that involves genuine regulatory ambiguity — a new bulletin with unclear operational implications — must be reviewed by the human CCO and, where needed, legal counsel before the journey goes live.