Skip to content
Lending Agent

Vulnerability process

The agent flags vulnerability indicators. It does not assess them. The broker’s process is what runs after. This page covers how to wire the agent’s vulnerability_flagged events into the broker’s existing vulnerability case-management, what response time to commit to, and the design constraints that keep the system honest.

The starting point is unambiguous: the agent is not authorised to make a vulnerability assessment. Cross-link to /regulatory/vulnerable-customers/ and /safety/vulnerable-customer-protection/ for the regulatory context. The agent’s job is to surface signals; the broker’s job is to act on them.

What the agent records

Section titled “What the agent records”

The agent emits a record_vulnerability_indicators event with a structured payload:

{
  type: "record_vulnerability_indicators",
  data: {
    indicators: string[],       // e.g. ["bereavement_recent", "income_change"]
    note?: string               // optional free-text the customer offered
  }
}

The case store records this on CaseState.financial:

{
  vulnerabilityIndicators: ["bereavement_recent", "income_change"],
  vulnerabilityNote: "Lost partner three months ago, income now half what it was.",
  vulnerabilityCapturedAt: "2026-05-07T10:14:22.118Z"
}

The audit log records the event with the indicators and note. The note is sensitive: cross-link to /privacy/data-minimisation/. It is not transmitted to lenders.

A separate downstream event, vulnerability_flagged, fires on the broker’s outbound webhook when at least one indicator is set. This is the operational signal the broker’s process consumes.

The broker’s vulnerability queue

Section titled “The broker’s vulnerability queue”

The broker should have an existing vulnerability process. Plug Lending Agent into it; do not build a new one. The integration is a single webhook subscription:

POST /webhooks/vulnerability HTTP/1.1
X-Broker-Signature: ...
Content-Type: application/json


{
  "event": "vulnerability_flagged",
  "deliveredAt": "2026-05-07T10:14:25.001Z",
  "sessionId": "8a4f...",
  "indicators": ["bereavement_recent", "income_change"],
  "note": "Lost partner three months ago, income now half what it was.",
  "caseStatus": "customer_active",
  "auditUrl": "https://broker.example.com/audit/8a4f...",
  "delivery": { "id": "wh_...", "attempt": 1 }
}

The receiver enqueues the case onto the vulnerability team’s queue. The case is now in two states at once: still active in the agent journey, and active in the human review queue.

What the agent does next

Section titled “What the agent does next”

Two design choices, neither of which is universally right:

Option 1: pause the journey

Section titled “Option 1: pause the journey”

On a vulnerability_flagged event, the agent pauses further state-mutating progress until a human has reviewed. The customer sees a “we’d like to make sure we’re supporting you correctly, someone from our support team will be in touch shortly” message.

Pros: maximally protective. The customer is not pushed through a credit application while a vulnerability assessment is pending.

Cons: a customer who is fine but mentioned a recent bereavement in passing now has their journey halted. Some flagged indicators are not blockers; they are heads-up signals.

Option 2: continue the journey, surface to humans in parallel

Section titled “Option 2: continue the journey, surface to humans in parallel”

The agent records the flag, emits the webhook, and continues. The human team reviews the case asynchronously and can intervene if needed.

Pros: respects the customer’s autonomy and momentum. Most flagged customers are still suitable for the product they are pursuing.

Cons: requires the human team’s response time to be fast enough that they can intervene before the application is submitted to lenders. A multi-hour SLA on review while the customer is mid-journey leaves a gap.

The recommended pattern is a blended approach:

  • Soft indicators (e.g. recent bereavement, English not first language) flag without pausing. The human team reviews within 15 minutes and can intervene if needed.
  • Hard indicators (e.g. customer states they cannot afford the proposed payments, customer expresses confusion about what they are signing up for) pause the journey immediately. A human contacts the customer before the agent proceeds.

The taxonomy of indicators and the soft/hard split is a matter for the broker’s compliance team, not for the engineering team. The engineering boundary is: the agent emits the structured event, the broker’s policy decides what to do with it.

SLA expectations

Section titled “SLA expectations”

For the soft-flag review queue:

  • First-touch review. A trained human looks at the case within 15 minutes during business hours, 60 minutes out of hours.
  • Customer contact. If the human elects to intervene, they make contact within 30 minutes during business hours, the next morning out of hours.
  • Alternative communication channels. The customer should be able to switch from chat to phone, video, or in-person if that suits them better. The broker advertises a phone number on every customer-facing page.

For the hard-flag pause queue:

  • First-touch review. Within 5 minutes during business hours, 30 minutes out of hours.
  • Customer contact. Within 15 minutes during business hours, 60 minutes out of hours. If outside service hours, the customer should be told this before the journey paused, with an explicit time the broker will call back.

Without these SLAs, the vulnerability flow is paper. Cross-link to /regulatory/consumer-duty/: a slow vulnerability response is the kind of foreseeable harm Consumer Duty asks brokers to prevent.

Wiring vulnerability_flagged to a queue

Section titled “Wiring vulnerability_flagged to a queue”

The simplest production wiring:

agent ──[record_vulnerability_indicators event]──▶ case store
                                                       │
                                                       ▼
                                            audit_outbox row
                                                       │
                                       worker drains, emits
                                                       │
                                                       ▼
                                       webhook to vulnerability
                                       team's case-management
                                       (Salesforce queue, ServiceNow,
                                        whatever the broker uses)

The webhook subscription is separate from the case_outcome subscription. The vulnerability team is a different audience with different access requirements. Most case-outcome receivers should not see vulnerability free-text notes; cross-link to /privacy/data-minimisation/.

In code, the dispatch is:

async function dispatchVulnerabilityFlag(c: CaseState) {
  if (!c.financial.vulnerabilityIndicators?.length) return;
  await webhookQueue.enqueue({
    event: "vulnerability_flagged",
    sessionId: c.sessionId,
    indicators: c.financial.vulnerabilityIndicators,
    note: c.financial.vulnerabilityNote,    // sensitive; subscriber must justify access
    caseStatus: c.status,
    deliveredAt: new Date().toISOString(),
  });
}

The vulnerability webhook subscription is access-controlled at the broker side: only the vulnerability team’s downstream receivers can subscribe. The retailer’s CRM does not subscribe to this stream.

What the human can do from the audit page

Section titled “What the human can do from the audit page”

When a vulnerability reviewer opens the audit page for a flagged case, they should be able to:

  • See the full conversation context, not just the indicator payload.
  • Add a note to the case that becomes part of the audit log.
  • Override the journey: pause, resume, or transfer to a human-led case.
  • Trigger an outbound contact (phone task, SMS, email) from inside the audit page.
  • Mark the review complete with an outcome: “no action”, “intervention”, “transfer to human”.

The review outcome is itself an audit event. The audit log shows: indicator flagged, reviewer assigned, review duration, outcome. That is the broker’s evidence of a working vulnerability process.

Soft-launch

Section titled “Soft-launch”

When wiring the vulnerability process for the first time, run a 30-day soft-launch where the human team reviews every flagged case regardless of severity. This serves two purposes:

  1. The team learns the agent’s flag patterns. Indicators they expect to see, indicators that surprise them, false-positive patterns they need to recalibrate the agent against.
  2. The taxonomy of soft and hard indicators is empirical, not theoretical. After 30 days of observation, the compliance team can codify which indicators warrant pausing.

After soft-launch, switch to the blended approach with the agreed taxonomy.

What to never do

Section titled “What to never do”
  • Do not assess vulnerability inside the agent. The agent records signals; humans assess.
  • Do not skip the probe. Every case must record a vulnerability check, even if the result is no indicators flagged. Cross-link to /regulatory/vulnerable-customers/.
  • Do not let lenders see the free-text vulnerability note unless there is a contractual basis. Cross-link to /implementation/lenders/data-minimisation/.
  • Do not aggregate vulnerability data into marketing analytics. The data is collected for a regulatory purpose; using it for another purpose is unlawful under GDPR Article 5(1)(b).

See also

Section titled “See also”