AI Use Cases

Recommended for POC

New Infra Required

Bedrock

LPL AWS Foundation

Premise: The NLZ pipeline already has the raw material AI needs — structured events (Kafka), full audit trail, inline rules, and Refit-based integrations. Dropping AI in as discrete, inline steps or sidecar services is low-risk and leverages LPL’s existing Bedrock footprint (lpl-bedrock, account 267796212942). No re-platforming required.

Use Cases at a Glance

#	Use Case	Where it plugs in	Value	Effort	Risk
1	Fraud & anomaly scoring	Inline step between `ComplianceService` and Approval in `AvAchService`	High	M	Med
2	Rejection explainability	BFF response shaping in `investor-cash-mgmt-process-api`	High	S	Low
3	IRA distribution code classifier	Pre-submit advisor UI → feeds `TaxWithholdingService`	High	M	Med
4	Ops triage / RTT exception agent	Move Money ops dashboard (reads Kafka + audit + RTT)	Med-High	M	Low
5	Natural-language ACH request	New advisor UI layer → `cam-movemoney-process-api`	Med	L	High
6	Rule authoring assistant	Dev workflow (writes EligibilityService code)	Med	S	Low
7	Periodic ACH smart-scheduling	`cam-mm-backgroundservice-api` pre-execution hook	Med	M	Med
8	Transaction lifecycle narrator	Support/ops UI; reads audit trail on demand	Low-Med	S	Low

Recommendation for POC: lead with #1 Fraud Scoring (business champion from Compliance/Move Money) and #2 Rejection Explainability (read-only, 1–2 week demo). Both use existing Bedrock access; no new infra.

1. Fraud & Anomaly Scoring Recommended

Problem: Retirement accounts are prime targets for elder abuse, account takeover, and social-engineering withdrawals. Current OLZ and NLZ both rely on static FICO/ComplianceService rules — no behavioral scoring.

What it does

Scores each ACHD / ACHC request against the investor’s historical pattern: amount vs. account balance, destination bank entropy, velocity (N requests in X days), geolocation mismatch.
Flags for review above a tunable threshold; auto-approves below.
Reason codes surfaced to Compliance queue (e.g., “amount 12× historical avg”, “new destination bank + large IRA”).

Where it plugs in

New inline step between ComplianceService (step 6) and Approval (step 7) in AvAchService — keeps the 10-step pipeline intact, just adds a fraud-check gate.

Implementation

Model	Bedrock Claude (tool use + structured output) for v1; consider in-house XGBoost/Isolation Forest when volume justifies
Features	Transaction audit history (cam-movemoney-system-api), account balance, account age, prior bank instructions, advisor “usual” patterns
Latency budget	≤ 500 ms P95 (pipeline SLA is 5s total); fall open on timeout to Compliance manual review
Governance	Legal + Compliance signoff required; model risk management; audit every inference (input hash + score + decision)
Key dependencies	Babujee Arumugam (NLZ pipeline integration), Compliance team (threshold + reason code taxonomy), LPL AI/ML governance

2. Rejection Explainability Recommended

Problem: Today, when Eligibility or Compliance rejects a request, the advisor gets a terse code (“BUSINESS_RULE_VIOLATION”). They call support, support escalates, engineering reads the rule — burns hours per incident.

What it does

Takes the structured rejection (rule IDs, triggered conditions, account context) and produces a friendly explanation: “This withdrawal was blocked because account QMM has a 90-day hold from recent deposit — hold expires 2026-05-12.”
Suggests remediation: wait, reduce amount, switch to GROSS, contact branch ops.
No impact on the transaction path — purely a response-shaping layer.

Where it plugs in

BFF layer — investor-cash-mgmt-process-api response interceptor. When process-api returns non-success, BFF enriches the body with friendlyReason and suggestedActions[].

Implementation

Model	Bedrock Claude Haiku (cheap, fast, 200-token output)
Input	Rejection code + rule metadata + anonymised account context (no PII in prompt — use tokens like `{ACCOUNT_TYPE}`, `{AMOUNT}`)
Latency budget	≤ 800 ms; degrade gracefully to static messages on timeout
Caching	Prompt cache on rule-ID prefix; LRU on the first N chars of rejection reason
Risk	Low — read-only, no transaction-path risk; worst case is a bad explanation, advisor falls back to raw code

Why this first: demonstrable in days, zero transaction-path risk, immediate advisor-support value — perfect showcase that AI delivers on Day 1 of NLZ.

3. IRA Distribution Code Classifier

Problem: 57 account types × 10+ IRS distribution reasons (early, normal, rollover, RMD, Roth conversion, 72(t) SEPP, disability…). Misclassification = wrong 1099-R = IRS penalty exposure.

What it does

Advisor types free-form intent: “client is 58, needs $40k for first-time home purchase, from traditional IRA”.
Model returns IRS code (code 02 – early distribution, exception) + flags review-worthy edge cases.
Drives TaxWithholdingService defaults and 1099-R coding downstream.

Where it plugs in

Pre-submit advisor UI. Result fed into the request payload before it hits cam-movemoney-process-api. Human-in-the-loop — advisor confirms.

Key dependency: Michael Mcguire + Tax/Compliance to ratify the classifier’s taxonomy and accuracy bar.

4. Ops Triage / RTT Exception Agent

Problem: When a transaction stalls (RTT timeout, BETA outage, Kafka producer failure), Move Money ops digs through Dynatrace + Kibana + audit trail manually. MTTR is hours.

What it does

Agent reads: Kafka events for the transactionId, audit trail from cam-movemoney-system-api, RTT status, Dynatrace problems in the window.
Output: root-cause hypothesis + suggested next action (retry, escalate to BETA L2, contact receiving bank, mark as NIGO).
Always suggests, never executes. Ops clicks “do it.”

Where it plugs in

Sidecar service; Move Money ops dashboard. No change to the pipeline. Reads only.

Key dependency: Puneeth Rangaswamy (ops patterns), Babujee Arumugam (Kafka schema access).

5. Natural-Language ACH Request (Advisor-Facing)

Problem: Advisor UI has 20+ fields per request. Error-prone, training-heavy.

What it does

Advisor types: “$50k from Jane’s IRA, gross, to her Chase checking…“. LLM structures into a TransactionRequest. Advisor reviews the form, submits.

Risk

High risk — hallucinated amounts, wrong accounts, misparsed percentages. Acceptable only if every field is shown for confirmation (the LLM can’t auto-submit). Treat as UX sugar, not core path.

6. Rule Authoring Assistant

Problem: New account types or regulatory changes require hand-coding new EligibilityService rules. Bottleneck on engineering.

What it does

Move Money analyst writes a rule in English (“block withdrawal from Roth IRA if account < 5 years and amount > $10k and reason != first-time home”). LLM generates the C# rule class + xUnit tests. Engineer reviews, merges.

Where it plugs in

Dev workflow only — not runtime. Generates code that goes through normal PR review.

Value: cuts time-to-market for new rules from days to hours. Human review gate means hallucination risk is bounded.

7. Periodic ACH Smart-Scheduling

Problem: Recurring ACH sometimes fires on a date with insufficient balance → NSF → failed transfer, client frustration, support escalation.

What it does

Pre-execution hook in cam-mm-backgroundservice-api: forecast next N days of cash flow using historical deposit cadence and known scheduled outflows.
If forecast balance on scheduled date < amount: alert advisor, suggest date shift, or auto-retry next business day (per config).

Risk

Adds complexity to a scheduler that already has double-execution concerns (see Unknowns #8). Consider only after the scheduler itself is stabilized.

8. Transaction Lifecycle Narrator

Problem: Support/dispute calls require reading raw audit rows to explain what happened to a transaction.

What it does

On demand, ingests audit rows for a transactionId and produces a plain-English timeline: “2026-04-22 10:14 — advisor submitted $5,000 ACHD from QMM. Eligibility passed. Compliance passed at 10:14:02. BETA hours open, auto-approved. RTT Submitted at 10:14:03, Completed at 10:14:11. Kafka event published.”

Where it plugs in

Read-only; any UI (support console, advisor portal). Purely a presentation-layer nicety.

Pipeline: Where AI Inserts

Step	Today (NLZ pipeline)	AI Addition
1 — Parallel account fetch	AccountDetails + Restrictions + Transfers + Beta	—
2 — Validate	FluentValidation	—
3 — Insert DB	cam-movemoney-system-api	—
4 — Notify (fire-and-forget)	BackgroundWorkQueue	—
5 — RTT Submitted	IRttClient	—
6 — Inline EligibilityService	C# rules engine (BBK/BFL/BMM today)	AI UC #6 — Rule authoring (dev-time only, generates rule code)
7 — Inline ComplianceService	Static compliance rules	AI UC #1 — Fraud & anomaly scoring (inline, between Compliance and Approval)
8 — Approved + audit	Audit row written	—
9 — Check BETA hours	BETA cutoff logic	—
10 — Completed + RTT + Kafka event	Event published	—
Rejection path	Return error code	AI UC #2 — Rejection explainability (BFF response shaping)
Advisor UI (pre-submit)	Structured form	AI UC #3, #5 — IRA code classifier, NL request
Ops/support tooling	Manual log digging	AI UC #4, #8 — Triage agent, lifecycle narrator
Periodic scheduler	cam-mm-backgroundservice-api timer	AI UC #7 — Cash-flow forecast pre-hook

Tradeoffs & Governance

Concern	Mitigation
PII in prompts	Tokenize account numbers, SSN, amounts before sending to LLM. Only send minimum necessary. Validate Bedrock data residency + no-retention settings.
Model risk (1099-R, eligibility)	Any AI affecting money movement or tax reporting goes through LPL model risk management. Start with advisory/explanatory use cases (UC #2, #4, #8) to build governance muscle before UC #1/#3.
Latency impact on 5s SLA	Every inline AI step has strict budget + fall-open fallback. Prefer async/sidecar where possible.
Regulator audit	Log every inference: input hash, model ID, version, output, decision. Required for SEC 17a-4 books-and-records.
Cost	Claude Haiku for high-volume cases (UC #2); Claude Sonnet/Opus reserved for complex reasoning (UC #4 ops agent).
Hallucination	All user-facing explanations cite rule IDs; classifiers return confidence + show raw evidence. Never auto-execute — human in the loop.

Next Steps

Week 1: Prototype UC #2 (Rejection Explainability) against Bedrock Claude Haiku. Feed 20 real rejection samples. Get advisor feedback.
Week 2: Design doc for UC #1 (Fraud Scoring). Data access pattern with cam-movemoney-system-api. Meet with Compliance on threshold + reason codes.
Week 3: Bedrock data-residency + governance signoff for transaction-path use. LPL AI/ML risk council review.
Week 4: UC #2 production pilot behind a config flag (same pattern as NEW_MOVE_MONEY_API_ENABLE) on 1% of traffic. Metrics: advisor call deflection, support ticket volume.
Beyond: UC #1 inline on NLZ Day 1 (gated behind canary). Expand UC #4 to ops. UC #3 after Tax/Compliance ratify taxonomy.

Bottom line: AI here is not a re-platform — it’s a set of discrete, mostly-read-only services that ride on top of NLZ’s already-excellent event and audit infrastructure. Start with low-risk explainability, graduate to transaction-path scoring once governance is in place.