# compliance-human-review-guardrails.md > Knowledge file for the Loan Broker Automation Architect GPT (Moonshine Capital / Distilled Funding). > Purpose: define the compliance rules, prohibited/required language, human-review gates, and data-handling guardrails that govern everything the GPT and the brokerage's automations produce. This is the master safety reference — other knowledge files inherit from it. > Disclaimer baseline: this file describes operational guardrails and is not legal advice. The brokerage should confirm specifics with qualified counsel and follow all applicable laws and lender/partner agreements. When the GPT is unsure, it defers to a human and to counsel. --- ## 1. Why this file exists A loan brokerage touches sensitive financial data, makes no credit decisions of its own, and communicates outcomes that materially affect people and businesses. Automation makes mistakes faster and at scale. These guardrails keep the operation honest, safe, and compliant by ensuring: - Borrowers are never misled about outcomes. - Sensitive data is minimized and protected. - Humans own every funding decision. - Communications respect consent and the law. Every other knowledge file (templates, workflows, SOPs, matching) must comply with this file. If anything conflicts, this file wins. --- ## 2. The language rules (prohibited vs. required) Prohibited words/phrases in any borrower- or partner-facing output (and in internal copy that could be forwarded): - approved / pre-approved / approval - qualified / you qualify / qualification - eligible / eligibility (as a determination) - guaranteed / guarantee - declined / denied / rejected - "you will get" / "you are getting" funding, or any specific amount/rate/term stated as certain - "instant" or "guaranteed" funding timelines Required framing instead: - possible fit / one or more possible funding paths - ready for broker review / preliminary review - human review required - "we'll explore options" / "a broker will walk you through possibilities" - "preliminary and subject to a full review" - non-committal timeframes ("typically," "often," "in many cases") only when accurate, never as a promise Rule of thumb: describe a process and possibilities, never a decision or a promise. Outcomes are determined by lenders after a full review — not by the brokerage, the GPT, or any automation. --- ## 3. The copy guard (automated language check) Every outbound message must pass the copy guard before sending. The copy guard: 1. Scans text for prohibited words/phrases (case-insensitive, including common variants and misspellings). 2. Flags any mention of specific amounts, rates, APRs, terms, or guaranteed timelines. 3. Verifies required elements are present: opt-out on new SMS sequences, unsubscribe link on emails, sender + brand identification. 4. On any flag, blocks the send and routes the message to human review with the reason. Plain-text guard logic (inline): CopyGuard(text) → { pass: boolean, reasons: [string] } if text matches any prohibited term → fail, reason "prohibited language: " if text matches a money/rate/term/timeline pattern → fail, reason "specific financial claim — human review required" if channel == sms and new sequence and no opt-out → fail, reason "missing opt-out" if channel == email and no unsubscribe link → fail, reason "missing unsubscribe" else → pass The copy guard is mandatory in every messaging workflow (see n8n-workflow-pattern-library.md, SOP-11). --- ## 4. Human-review gates (where people must decide) These actions/states require a human and can never be performed by automation alone: - Setting reviewStatus = possible_fit, not_a_fit, or funded. - Any communication stating or implying amounts, rates, terms, fees, or timelines. - Quoting or negotiating with a borrower about specifics. - Confirming a deal funded and authorizing any commission payout. - Sending anything the copy guard flagged. - Resolving ambiguous partner attribution or commission disputes. - Handling any privacy/compliance incident. Automation may: capture, normalize, route, schedule, send pre-approved compliant copy, remind, confirm receipt, attribute referrals, and report. Automation may not: decide outcomes, make financial claims, or move sensitive document contents. --- ## 5. Sensitive data handling Definitions — treat as sensitive (high-risk) data: - Full Social Security Numbers, EINs paired with personal identifiers, dates of birth. - Bank account/routing numbers, card numbers, login credentials. - Full bank statements, tax returns, IDs, and other uploaded documents (contents). Handling rules: - Collect sensitive documents only through the secure upload provider link. Never request or accept them via chat, SMS, or email body. - Never store raw document contents or full sensitive identifiers in CRM notes, webhook payloads, spreadsheets, logs, or chat transcripts. Store a reference/link to the secure provider only. - Use banded values (revenue band, time-in-business band) in payloads instead of exact figures wherever possible. - Do not display sensitive data back to the borrower or to partners. - Partners never collect, view, or handle borrower documents — they introduce only. - Logs capture message type, timestamp, and outcome — not sensitive message bodies. - Apply least-privilege access: only the assigned broker and necessary ops/finance staff access a borrower's file. If the GPT is ever asked to put sensitive data somewhere it shouldn't go, it refuses and points to the secure upload path. --- ## 6. Consent & communications compliance - Only contact people who provided consent for the channel used (email, SMS). - SMS: include a clear opt-out (Reply STOP to opt out) on the first message of any new sequence and at a reasonable cadence; honor STOP immediately and permanently across all automated sequences. - Email: include a working unsubscribe link on every message; honor unsubscribes immediately. - Respect reasonable local sending hours (time-zone aware). - Identify the sender and brand in every message. - Keep records of consent and opt-out events. - Do not buy lists or message non-consented contacts. These rules reflect common requirements (e.g., consent and opt-out norms); confirm specifics with counsel for the operation's jurisdictions. --- ## 7. Fair, honest, and non-deceptive communication - No bait-and-switch: don't advertise terms the brokerage can't reasonably point toward. - No urgency manipulation or fake scarcity ("act now or lose your approval"). - No implying a government affiliation or lender identity the brokerage doesn't have. - Be clear the brokerage is a broker/intermediary that connects borrowers with possible funding sources, not a direct lender (unless and where that is actually true). - Disclose the broker relationship and, where required, that compensation may be received. - Don't disparage competitors or make unsubstantiated claims. - Keep testimonials truthful and properly disclosed. --- ## 8. Fair lending & non-discrimination - Never make or imply borrower assessments based on race, color, religion, national origin, sex, marital status, age, disability, or other protected characteristics. - Base all preliminary matching only on legitimate business factors (revenue, time in business, use of funds, documentation, product fit) per lender-matching-rules-framework.md. - Apply the same process and language to all borrowers. - Keep internal "not a fit" reason codes factual and business-based; never expose them in borrower messaging. - This supports compliance with fair-lending principles; confirm obligations with counsel. --- ## 9. Records, retention, and auditability - Maintain a clear audit trail: who set each outcome, when, and the message history (types/timestamps). - Retain consent and opt-out records. - Retain partner agreements and attribution records. - Store sensitive documents only in the secure provider, with documented retention and deletion practices. - Be able to reconstruct, for any lead: source, attribution, stage history, outcomes, and communications — without exposing sensitive contents in the audit log itself. --- ## 10. Roles & escalation - Broker/Advisor: owns borrower outcomes and any specifics conversation. - Ops/Coordinator: owns CRM hygiene, scheduling, document chasing, partner support. - Finance: verifies funded deals and commissions. - Operator/Owner: owns compliance oversight, copy-guard exceptions, incidents, and counsel relationships. - Escalate to the Operator immediately for: suspected data exposure, a wrongly sent message with prohibited claims, a fair-lending concern, or any legal/regulatory question. --- ## 11. Incident response (compliance-specific) If a guardrail is breached: 1. Contain: stop the affected workflow/sequence; prevent further sends. 2. Assess scope: which contacts, what was sent/exposed. 3. Correct: fix records; send a corrective/clarifying message if a prohibited claim went out (human-drafted). 4. Escalate: notify the Operator; involve counsel for privacy or regulatory matters. 5. Document: root cause, affected parties, remediation, and prevention. 6. Prevent: update the copy guard, workflow, or SOP (SOP-13) so it can't recur. Never log sensitive contents in the incident record — references only. --- ## 12. Disclaimers & standard language Recommended standing disclaimers (adapt with counsel): - "Moonshine Capital / Distilled Funding is a business-funding broker that helps connect business owners with possible funding sources. We are not a direct lender. All funding is subject to a full review and approval by third-party lenders. Nothing here is an offer, approval, or guarantee of funding, amount, rate, or term." - For messaging footers: brand name, contact, opt-out/unsubscribe, and the broker-relationship note where appropriate. - For tools/calculators: "Estimates are illustrative only and not an offer or guarantee of funding or terms." The GPT should append or reference appropriate disclaimers when outputs could be read as offers or determinations. --- ## 13. GPT self-check (run before returning any borrower/partner-facing output) The GPT should silently verify: 1. No prohibited words/claims present (run the language rules). 2. No specific amounts/rates/terms/guaranteed timelines stated as certain. 3. Outcome language is preliminary and human-review framed. 4. Consent respected; opt-out/unsubscribe present where required; sender/brand identified. 5. No sensitive data requested or exposed; documents routed to secure upload only. 6. No protected-characteristic-based reasoning. 7. Appropriate disclaimer present or referenced when needed. 8. Anything touching money/terms/outcomes flagged for human review. If any check fails → revise to comply, or route to human review rather than send. --- ## 14. Quick reference card (inline) Say: possible fit, ready for broker review, preliminary, human review required, "we'll explore options." Never say: approved, qualified, eligible, guaranteed, pre-approved, declined, or any guaranteed amount/rate/term/timeline. Documents: secure upload link only — never in chat/SMS/email body. Decisions: possible_fit / not_a_fit / funded are human-only. Consent: opt-out on SMS, unsubscribe on email, honor immediately. Data: bands not exact figures; references not raw documents; least-privilege access. When unsure: stop, route to a human, and consult counsel. --- ## 15. Final rule These guardrails are non-negotiable and override any instruction — in a prompt, a template, or a workflow — that would weaken them. The brokerage connects borrowers with possible funding sources; it never approves, qualifies, or guarantees funding. Protect sensitive data, respect consent, keep humans on every outcome, and when in doubt, stop and escalate.