Integrations
Each system the service reads from and writes to, what it reads, what it writes, and the access it uses: always access you already hold.
Updated 2026-09-22
The service works through access you already hold: the files you already receive, where they already land, and the API access you already pay for. Nothing new is built on your side. Each installation's feed mappings and integration contracts are written at onboarding from your data dictionary and a sample night, each with a replay test. This page is the standard set.
What it reads
| System | What it reads | Through |
|---|---|---|
| ICE MSP | The Bulk Data Extract, eCDE and RDO files; task and field state every fifteen minutes | The location the nightly files already land in; your MSP API access |
| Sagent LoanServ | The Bulk Data Ops export; task and event state | The location the export already lands in; Sagent's APIs |
| Epiq AACER | The bankruptcy match file | Its existing drop |
| Your attorney portal | The status export | Its existing drop |
| The shared mailbox | Attorney email bodies and attachments | Microsoft Graph, delta synchronisation, one mailbox |
| Your imaging system | The export for loans in default, with a manifest mapping each file to its loan | Its export |
| Your claims tool | The complete claim record, at conveyance or CWCOT title | Its API |
| HUD remittance advices | What HUD paid on each claim, for reconciliation | Your existing drop |
| The public court record | County dockets and bankruptcy dockets for your loans | Proxara's signed bundle, pulled |
The feed rows are mapped by code and never reach the model. The model reads only the documents: the mail, the imaging export and the court record.
What it writes
| System | What it writes | Through |
|---|---|---|
| ICE MSP | Extended deadlines, holds and re-projections in the foreclosure and bankruptcy workstations' own fields; a note in the loan history saying why; a task only when an answer or an action is needed | Your Interchange and DIS access |
| Sagent | The same | Its task, event and field write APIs |
| Your claims tool | The merged claim: the extended dates, block 19, the Mortgagee's Comments and the evidence references, validated against HUD's claim-type requirements | Its API |
| Your imaging system | The documentation bundle and the claim-file manifest, filed to the loan's folder | Its API |
| One SharePoint library | One loan summary per loan, regenerated when the loan changes, and the portfolio workbook snapshot | Microsoft Graph, one library |
| The shared mailbox | One digest each morning to the person who owns the number | Microsoft Graph, Mail.Send on that mailbox |
| HUD Catalyst | The claim as JSON, where you submit direct | Prepared for you; never submitted |
The service never submits anything. A lender employee certifies and submits every claim, and the service records the submission from the claims tool's state.
Decisions
A question reaches your team only when a fact the record cannot settle is missing, or when your policy makes that class of extension yours to decide. The answer is read back as an explicit result on the task (accepted, rejected, or corrected with the correction), with who gave it, and applied within fifteen minutes of the poll that reads it. A task that is merely closed is not a decision, and is asked again.
Your policy is a file in your SharePoint library, set at onboarding per class of extension. Any class can be moved either way.