About Forbear

Yolanda ran servicing at a debt settlement firm with 14,000 open files and a CRM that had been customized for nine years. Every vendor that came through the door sold the whole thing: sales, servicing, negotiation and reporting in one modern system, with AI doing the repetitive parts. Every demo ended at the same question, which was what happens to nine years of custom fields, creditor mappings and state license logic. Nobody had a good answer, so nobody bought, and the repetitive work stayed manual for another year.

Forbear does the AI part and refuses the rest. It connects to the CRM already in place, reads the creditor correspondence attached to each file, extracts the settlement offer terms, and writes them back into the fields that system already has. There is no Forbear record of a consumer, no Forbear inbox, no Forbear pipeline view. If it is switched off on a Friday the firm still has every file, in the system it has always had them in.

The work is document reading and it is genuinely dirty. Creditor responses arrive as portal screenshots, faxed letters, PDF attachments with the offer buried in a paragraph, and phone notes typed by whoever took the call. Forbear reads it with models and uses rules only where they are cheaper. Template rules take the largest creditors, because those letters are laid out the same way every time, but 34% of incoming documents match no rule, and that third is where the models do the work. A model reads the page and proposes four values, the balance, the settlement amount, the payment schedule and the expiry date, and returns each one with a confidence score and the sentence it was read out of, so a person can check the figure against the line rather than against the whole letter. Without the models, a third of the mail would sit unread and every new creditor would wait for somebody to write a rule, which is the honest measure of how much of this product is the model.

When the model is not sure enough, nothing is written anywhere. The document goes to a negotiator with the proposed figures sitting beside the page they came out of, and a person says yes to each one or fixes it. What a negotiator accepts gets written into the CRM with the document attached to it. What a negotiator corrects gets written in too, and we keep the correction next to what the model had guessed. A pair is the page region, the four proposed values, the confidence we had, and what the person put there instead. Not the document, which stays the firm's, and not a consumer identifier, which is stripped before the pair is stored. That is how the models learn the next creditor's letters without a template being written by hand: from somebody who was looking at the letter, not from us guessing from the outside. The pile of pairs is ours, it is detached from the firm it came from, a firm can opt out of contributing to it in its connection settings, and it grows every time somebody clears a queue.

The computing comes in two lumps rather than a steady trickle, and it splits by what it does. The reading runs on Microsoft Azure in East US: Azure AI Document Intelligence parses scans and screenshots, Azure OpenAI reads whatever no rule matches, and Azure Machine Learning retrains the extraction models. Everything around the reading runs on AWS in us-east-1: intake, the review queue and the embedding runs on EC2, and the source documents and the search index in S3. Storage is the one line that only ever grows, in S3 for the archive and in Azure Blob Storage for the write record. The first lump is a new firm's back catalog: years of creditor mail, tens of thousands of documents, all read in one batch so that week one already has history behind it instead of an empty screen. The second is the ordinary working day, which is not evenly spread either, because creditor post arrives in the morning and settlement batches clear at the end of the month. Parsing a scanned or screenshotted page into something a model can read is flat out inside those windows and idle between them, so it wants capacity that comes and goes rather than capacity that sits. And the search that finds a matching past document embeds every document in the book, not only the 34% no rule matches, which makes the index the one part of this that grows with the whole archive rather than with the residue.

Consumer financial data cannot travel to an inference API nobody has reviewed. Every firm we have spoken to runs a vendor review before it will even sit through a demo, and the review always asks where the reading actually happens. We can answer in one sentence: the pages are read by Azure OpenAI and Azure AI Document Intelligence in East US under zero-retention terms, so Microsoft keeps no document and trains nothing on one, while the documents themselves stay in S3 in us-east-1, where the firm's mail arrives. What is still unfinished, and dated, is our own extraction models: across 2026 and 2027 we fine-tune them on Azure Machine Learning from the corrections our negotiators made, so fewer pages need a general model and each page costs less to read. On AWS, what grows is the archive: every document in every book, and the EC2 capacity each new firm's backfill needs.

There are three of us and we incorporated in Delaware in 2026. Four firms pay $1,200 a month per connected CRM, flat, and billing starts when a reviewer accepts the first extraction rather than when the connection is made. Nobody has invested. The awkward part is that the backfill is the largest compute event in the product, we charge nothing for it, and it has to stay affordable as the number of firms grows.