> ## Documentation Index > Fetch the complete documentation index at: https://docs.myfundingmachine.com/llms.txt > Use this file to discover all available pages before exploring further. # Heloc process # HELOC for Business process Status: canonical\ Last updated: 2026-09-06 ## Scope Funding Machine supports an assisted-booking business-purpose HELOC process. The Operator and Applicant attend a call with the 7 Figures fulfillment team, which owns lender fulfillment. Funding Machine does not call the Figure API or send Applicants to a direct-apply link. The full experience is gated by the location-scoped Labs feature `heloc-for-business`, which is visible and enabled by default (FM-2497). The Labs toggle remains the rollback: when the feature is turned off, the product is Coming Soon and no form, product selection, workflow, or funding category is available. ## Lifecycle 1. The Applicant submits the Operator's application. 2. Funding Machine automatically derives a HELOC Prescreen from the selected credit report and the application-submitted address. 3. The Operator or Applicant completes Eligibility Confirmation. 4. An Eligible confirmation unlocks HELOC in the product plan. 5. The Operator completes the HELOC workflow and schedules a call attended by the Operator, Applicant, and 7 Figures fulfillment team. 6. Confirmed or booked files enter the separate HELOC fulfillment queue. 7. The fulfillment team maintains the HELOC funding row through funding. 8. The Operator sends the consulting fee invoice. HELOC never contributes to the MFM 15% processing-fee basis. ## Stage 1: HELOC Prescreen Inputs: * FICO from the credit report * mortgage-family tradeline present on the report (homeowner proxy) * stated-income DTI from `underwritingResults.dti` * state from the address submitted on the Operator's application Only FICO below 640 is a hard `ineligible` result. A missing mortgage, an ineligible or unknown state, DTI above 45%, or unavailable inputs produce `not_prequalified_soft`. Soft results explain that a paid-off home may not show a mortgage, another property may be in an eligible state, and 25% of business income may improve verified DTI. The confirmation form can overturn them. A clean screen is `prequalified`, pending Eligibility Confirmation. It is not a credit decision or offer. California remains disabled. State eligibility is the Figure SMB matrix dated 2026-05-12 in `lib/funding/helocStateEligibility.ts`. ## Stage 2: Eligibility Confirmation One location-and-contact scoped record stores: 1. property state 2. primary residence yes/no 3. mortgage balance 4. estimated home value 5. existing liens 6. verified personal monthly income 7. average monthly business income 8. percentage of the business owned by the Applicant Mortgage-family accounts found on the credit report prefill the mortgage and lien answers; the Operator or Applicant confirms their type and balance and may add manual liens. Contact annual personal income prefills the monthly field. The Operator can complete the form in-app or issue a short-lived tokenized `/heloc/eligibility?token=…` link. This is a Funding Machine portal, not a CRM form. Every Operator read and write is scoped by `locationId`; client submission is authorized by the single-use token. Preparing a new link creates a pending token and does not revoke a previously delivered active link. Only successful delivery activates the prepared link and retires earlier delivered active links for the contact. Expiry is checked against the server clock, and the link stops rendering the form when Labs is later disabled for the location. A successful submission retires the link as submitted, so it cannot be reused. ### Definitive calculation * FICO floor: 640 primary residence; 680 non-primary * DTI: monthly credit-report debts divided by `verified personal monthly income + 25% × average monthly business income × (business ownership percentage / 100)` * Maximum DTI: 45% * CLTV: 85% primary; 70% non-primary * Estimated HELOC: `CLTV × estimated home value − mortgage balance − additional liens` * Minimum estimated HELOC: $25,000; $35,000 in Texas * State and state-specific occupancy restrictions must pass The stored verdict is exactly `eligible` or `ineligible`. Estimated amounts are Operator-facing only. The Operator dialog states the verdict where it was submitted — it stays open after submit and shows the verdict, reasons, estimated line, verifiable annual income, and recomputed DTI — and the HELOC tile badges that verdict once the form has decided. The prescreen also displays its badge, reasons, mortgage evidence, application-state source, and next action directly on the tile. A pass reads `Potentially eligible`, with property and equity still unconfirmed. Historical mortgage accounts do not establish current ownership. The Operator form previews the estimate, qualifying income, and DTI from the current answers. Ownership is explicitly entered when business income is used. New confirmations snapshot the source report, credit score, monthly debts, stated personal income, and annual business revenue. If these change, the Operator must re-check eligibility before plan selection; the server enforces the same check. Legacy records remain readable, but those using business income without ownership must be updated. HELOC does not join plan totals or fees. The Operator's property-state picker groups states by the matrix (eligible, eligible with conditions, not eligible) and names the consequence of the selected state before submission. The tokenized Applicant portal keeps a flat state list and shows no verdict: the approved-state footprint is confidential partner material and the restriction wording is Operator phrasing. Worked fixture from the underwriting sheet: * home value: \$300,000 * primary mortgage: \$205,000 * primary-residence CLTV: 85% * Estimated HELOC: \$50,000 * personal monthly income: \$8,000 * average monthly business income: \$20,000 * business ownership: 100% * verifiable annual income: `(8,000 + 25% × 20,000 × 100%) × 12 = $156,000` At 50% ownership the same business contributes $2,500/month, and qualifying annual income becomes $126,000 (Operator-requested revision, 2026-09-08). ## Product, workflow, and fulfillment HELOC is selectable only when Labs is enabled and the latest Eligibility Confirmation is Eligible. The server rechecks both facts when the plan is confirmed. The standalone workflow is: 1. Review & approve underwriting 2. Send client agreement 3. Review signed agreement 4. Schedule / attend call with the 7 Figures fulfillment team — the Operator and Applicant must both attend 5. Wait for HELOC to fund 6. Send consulting fee invoice The Operator — never the Applicant — books the fulfillment call, and only once the client's paperwork is in: the cycle-signed client agreement, plus the signed Processing Application on locations where the Processing Application gate applies (Brock + Kevin, 2026-08-25). Files the gate does not cover — gate-off locations and grandfathered contacts — are never sent the application form, so the signed agreement alone unlocks booking there. A contact the gate exempts because its completed agreement already carries the application — a legacy agreement sent before the Location verified the gate, or a manually verified Client App + Agreement upload — books on that agreement even when it was signed before the current underwriting cycle. A later cycle never re-papers such a client, so the cycle-scoped signature check alone dead-ended booking behind paperwork that already existed (fixed 2026-10-12). A bare grandfather override waives the form but proves no agreement exists, so it does not unlock booking by itself. Booking the appointment does not complete step 4. The appointment remains visible on that active step until the Operator completes it. A **Showed** disposition lets the Operator complete it directly; otherwise the app asks the Operator to confirm that both they and the Applicant attended before moving on. After completion, the appointment details collapse and step 5 becomes the next action. A **No-show** or **Cancelled** disposition keeps step 4 open and offers **Book Again**. The HELOC-only checklist always uses the plain agreement step labels. In mixed plans the agreement steps are shared with the other selected products, so the Processing Application variants appear whenever the location's gate applies to that path. The schedule and wait steps appear before term-loan or card steps. The Funding tab uses the term-loan fields and financial statuses: rate, term, funding status, amount; Not Started, Offer Accepted - Pending, Lender Approved, Lender Rejected, and Funded. The internal HELOC fulfillment queue is distinct from Processor work. A row appears once a confirmed HELOC funding plan exists and also when an operator booking request or an appointment is detected on calendar `ZWGlqBxQtZfvgatXjffj` in the admin Location pinned by `HELOC_FULFILLMENT_ADMIN_LOCATION_ID` in `lib/helocBooking.ts`, which can happen before confirmation. The queue deliberately presents three independent concepts: * **Appointment** is live CRM calendar time and disposition. * **Fulfillment status** is the persisted, manually managed workflow stage on the HELOC funding plan (`fulfillmentStatus`). It is shared with the contact file and is not inferred from appointment disposition. * **Funding result** is the HELOC funding row's financial `status` and `amount`. The old **Assigned to** and **Next action** cells were display-only derivations. The fulfillment system now creates or reconciles a real contact task through the existing per-Location CRM task path and stores its ID (`helocTaskId`) on the HELOC funding plan. The assigned user works that task in the Location's CRM **Action Center** (the same task feed shown on the Funding Machine dashboard). Signed appointment webhooks durably enqueue a Convex-scheduled worker. That worker re-reads the exact appointment, selects the canonical call, resolves the file, and creates/reconciles the task without any queue viewer. Queue GET is strictly read-only. A separate durable task-event worker also performs an authoritative `GET /contacts/:contactId/tasks/:taskId` and projects only the returned `completed` boolean to `helocTaskStatus`; it never trusts completion from the wake payload and never changes `fulfillmentStatus` or financial status. The sweep records `helocTaskStatusReconcileAt` when it enqueues each plan so retrying or blocked provider reads rotate behind unswept completed plans without falsely advancing `taskProjectionSyncedAt`. Each running reconciliation has a durable lease and scheduled watchdog. A worker interrupted by a deployment, timeout, or process failure is reclaimed within the bounded attempt budget instead of remaining `running`. Every reclaimed run receives a new claim token; an expired worker cannot cancel or finalize its replacement's watchdog/job state. The appointment refresh signal also requires a verified session identity bound to the requested Location (or verified global admin access) before its Labs gate; knowing a Location ID is not authorization. The canonical appointment's admin-calendar assignee maps by unique email to a user in the file's Location; the two Location-specific user IDs are never reused across identity spaces. Unmapped, duplicate, unavailable, missing-scope, and task-read failures display **Unassigned** or a task sync error with a retry action. A manual task-owner override remains sticky until an admin selects **Use calendar**. Cancellation and no-show retain the owner, update the open task for follow-up, set `followUpNeeded`, and do not complete the file. A small **Suggested** hint may still derive from live appointment/funding facts, but it is not workflow state. Task creation is idempotent by the stored task ID plus an `[FM_HELOC_PLAN:]` marker plus an atomic per-plan lease/revision fence. If the CRM accepts a create without returning an ID, automatic recreation pauses for the whole file (including after reschedule/reassignment). The same durable guard remains when transport drops the response, the provider returns 5xx, or a worker stops after persisting its create attempt; these outcomes may have committed and are not treated as definitive rejection. Later background reconciliation adopts one marker, while duplicate markers stop visibly. Affirmative 4xx rejection clears the attempt guard for bounded retry. **Retry task sync** is an explicit protected POST. Task writes run only when the existing token proves `locations/tasks.write`; sync never expands permissions. External task updates are fenced both before and after the awaited CRM request. If a write finishes after a newer owner/file revision, the stale worker cannot mark the file synced and durably queues another canonical-appointment reconcile. This makes the last late external completion cause a newest-state pass rather than leaving CRM assignment behind the sticky manual owner. Successful updates are also re-read before `helocTaskSyncState` becomes `synced`; title, body/file marker, normalized due date, completion, and owner must all match the intended projection. A missing or mismatched authoritative projection remains a visible sync error with the protected retry path. Durability starts at webhook ingress, before the watchdog exists. A transient Convex enqueue failure for the pinned HELOC calendar returns a retryable non-2xx response from both appointment entry points so the provider can redeliver it. Duplicate or stale redelivery remains an idempotent success. Appointment events for other calendars retain the existing delegated acknowledgement behavior. The primary marketplace documentation lists exactly `TaskCreate`, `TaskComplete`, and `TaskDelete` task webhook events. The marketplace webhook route accepts those documented strings through its provider Ed25519 signature path as authenticated wakes for stored HELOC tasks. `TaskComplete` contains no completion boolean or update-version timestamp; `dateAdded` is not treated as one. Duplicate deliveries are durably deduplicated; exact Location, Contact, task ID, and HELOC plan identity must match before a job is scheduled. `TaskDelete` followed by a 404 blocks visibly while retaining the stored task ID and last known `open`/`completed` projection; there is no invented cancelled task status. Live acceptance requires subscribing at least `TaskComplete` on the existing marketplace destination `/api/lb/webhook`; subscribe `TaskDelete` for automatic deleted-task visibility and `TaskCreate` for the additional creation wake. Primary docs do not list `TaskUpdate` or `TaskReopen`, and `TaskComplete` is called only when a task is completed, so it is not claimed as a reopen wake. Instead, a default-off Convex cron scans at most the 100 stalest plans currently projected `completed` every 15 minutes and enqueues the same authoritative task read. Fifteen minutes is the sweep invocation interval, not a per-record worst-case latency. With `C` eligible completed plans, batch size `B = 100`, and a stable population, every plan is selected within `ceil(C / B) × 15 minutes`. The separate `helocTaskStatusReconcileAt` advances whenever a plan is considered, including when an existing job is pending/running/retrying or a blocked job is requeued; failed checks therefore rotate without falsely changing `taskProjectionSyncedAt`. The selected batch dispatches immediately. A selected record whose provider read fails transiently can add retries at 1, 5, 30, and 120 minutes (156 minutes total), so eventual successful convergence is bounded by the population selection bound plus that retry budget when the provider recovers. An interrupted claim is reclaimed after its 15-minute lease within the five-attempt budget. A permanently unavailable connection has no finite per-record convergence guarantee, but it cannot prevent later records from being selected on subsequent sweeps. The automatic sweep requires deployed schema/functions, a valid Location task read token, and explicit `HELOC_TASK_STATUS_RECONCILE_ENABLED=true`. It ships disabled and is not production configuration authorization. Protected Retry remains an additional re-read path, not the reopen design. Vercel runs `convex deploy` only for a production build. A successful PR preview runs the Next.js build without deploying this branch's Convex schema or functions, so preview success does not prove that the preview frontend has a matching backend. Release preflight must verify a distinct preview Convex target and matching `APP_URL` / internal-secret configuration before any end-to-end acceptance or production enablement claim. ## Fee treatment HELOC funding rows are excluded from funded and pending MFM processing-fee basis calculations. Therefore they create no team-attributable entitlement and no HELOC processing-complete fee line. An Operator may still use Funding Machine's invoice conveniences for the client consulting fee. ## Sources and precedence 1. Underwriting sheet, 2026-08-24: 640/680 FICO floors, 45% DTI, 25% business income credit, CLTV and equity math. 2. Ty Talbot workflow guide, 2026-07-23: assisted fulfillment and HELOC fee exclusion. 3. Figure SMB Product Guide, approved-state list dated 2026-05-12: state matrix. When thresholds conflict, the 2026-08-24 underwriting sheet controls. ## Deliberately open * RentCast or another home-value API may replace manual estimated value later. * A Figure API integration may be evaluated later. * Neither item is part of the current assisted-booking launch. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.