The protection is in the data flow, not in a promise.

The engine runs inside your environment.

DoubleCheck is a single code-signed Windows executable. You put the extract folder beside it and run it. It reads the folder, replays the account histories, and writes the memo to a local path you choose.

It makes zero network calls. There is no license check, no telemetry, no update check and no endpoint to allowlist. Put the machine on a segment with no route out, or on no network at all, and DoubleCheck behaves identically.

That should be easy for your network team to approve, and it should not require taking our word for it. Three things make it checkable. We publish the SHA-256 hash of the executable you were sent, so you can confirm the binary in your hands is the binary we shipped. It is code-signed, so Windows will tell you if it is not. And the verification that settles it is to block the process at the firewall and run the review anyway: it completes, and the memo is byte for byte the memo you would have got with the network open, because there was never an outbound call to lose.

The security packet is available on request. It contains the file specification, the published file hash, the data handling detail on this page in a form you can circulate, and the model documentation.

What this costs you. You supply the machine and the person who runs it. A laptop holding the extract is enough, and there is no server to stand up, but Delegate cannot run it for you. That is the trade the architecture makes.

Identifiers are hashed before analysis, with a salt you keep.

The extraction script generates a random engagement salt on your side and writes it to a local file. Customer, account, and counterparty identifiers are replaced with SHA-256 of the salt plus the value before anything is analyzed. The same salt is used across every file, so the engine can see that two accounts share a payee without seeing who the payee is.

Delegate never receives that salt. It is not a field in any file the engine reads, and no code path transmits it.

The hashed identifiers are ordinary columns in the extract, named hashed_member_id, hashed_account_id and hashed_counterparty_id. The engine reads those columns and nothing else that could identify anyone. Your own mapping table, which never leaves the institution, is the only thing that turns one of them back into an account.

If the memo says account 0041188 should be reviewed, your team resolves that hash to a customer using your own salt file. Delegate cannot perform that step, because it does not have the input.

What this costs you. The salt file is a credential and has to be stored like one. Lose it and the memo's account references can no longer be resolved to customers, and the extract has to be regenerated from the core.

The full portfolio, not a sample you pre-selected.

The extract covers 36 months of de-identified history for the whole loan portfolio, not a subset. That is a larger ask of your IT team than a targeted pull. Here is why.

A synthetic identity looks ordinary one account at a time. It only stands out against the population. Ring is the clearest case: the signal is a cluster of accounts sharing funding or payee counterparties alongside clustered openings, and that pattern is only visible if the accounts it connects are all in the data. Narrow the extract to accounts you have already flagged and the cluster falls apart, because the accounts that complete it were never pulled.

The known charge-off file comes with the extract, but it is the answer key, not the input. The engine replays the portfolio point-in-time without it. The charge-off file is used afterward, to check what the signals caught and what they missed. Handing it to the engine up front would only tell you what you already know.

What the extract contains, and what it does not.

The specification is a fixed column list. There is no free-text field and no catch-all column.

What this costs you. Transaction and charge-off amounts are in the extract, because Ramp and Inflection are computed from them. The extract never leaves your machine, so those amounts do not travel anywhere. If your policy prohibits amounts in a working file even on your own hardware, raise it on the first call and we will tell you plainly what that rules out.

The extraction script enforces that list, and stops when it cannot.

The script passes through only whitelisted spec columns. It hard-fails if a column name looks like PII, SAR material, or consumer bureau material. Both checks run independently, so a column has to clear each one.

A core export that still carries member_name or fico_score stops the run with an error naming the offending column. It does not warn and continue, and it does not silently drop the column.

The script is stdlib Python, it ships as one readable file, and it carries a self-test you can run before you point it at anything real.

What this costs you. A malformed export means a second pull. The script will refuse rather than guess, and that refusal lands on your IT team's afternoon, not ours.

What leaves your building.

The memo, and only if you send it. The extract, the working files, and the salt stay on your machines for the whole engagement. There is no upload step anywhere in the process, and this site accepts no file of any kind.

You read the memo before Delegate does.

What this costs you. Delegate cannot debug a run by looking at your data. Instead, every run writes run_log.txt beside the memo: engine version, row counts, column names, the replay boundary, aggregate signal and disposition counts, stage timings, and the offending file or column when a run fails. It holds no identifiers, no amounts, and no per-account values, and the engine re-reads it before finishing and refuses to emit it if any appear. Troubleshooting goes through your operator and that file.

The output carries no scores and no dollar figures.

Every account returns one of three dispositions: pass, review, or fail, with the reason codes that produced it. There is no numeric score, no percentile, no rating, and no dollar amount anywhere in the memo. DoubleCheck runs on your data, inside your walls, and your team makes every decision. The output is also structured to avoid consumer-report score formats under FCRA.

A finding reads credit exposure sought is climbing far faster than genuine inflows into the accounts. It does not read a ratio, a percentage, or a loss estimate.

DoubleCheck is not a consumer report and Delegate is not a consumer reporting agency. The output suggests. Your institution decides.

On fair lending specifically. A disposition is the starting point for a human investigation and never a decision. Every fail is reviewed by your team before anything happens to an account, and no account is declined, closed, restricted or reported because this engine produced a disposition. The engine reads account behavior, not demographics: no protected characteristic, no proxy for one, and no geography is an input, and the extract does not carry them. The simulated population the thresholds were judged against was calibrated to published data on how much real income varies month to month, and that calibration was completed before any threshold was set, so the engine was tuned against a realistic population of honest customers rather than a tidy one. That population deliberately includes the people most likely to be misread for innocent reasons: seasonal staff, contractors and gig workers, retirees on fixed income, and customers supported by a relative.

What this costs you. There is no number to sort or rank by. Someone on your team reads reason codes and exercises judgment, which is more work than triaging a score column.

GLBA, and the basis for the engagement.

A review is structured as fraud prevention performed by a service provider under a written data processing agreement. GLBA permits a financial institution to disclose nonpublic personal information to a service provider to prevent actual or potential fraud, and the agreement sets the scope, the permitted purpose, the handling rules, and the destruction date.

In practice the question is narrower than it sounds, because the data is de-identified before it is analyzed and the analysis runs on your equipment.

What this costs you. The agreement has to be signed before any extract is generated, and your counsel should read it against your own privacy notice and vendor management policy. Delegate does not opine on whether the framing fits your institution. That judgment is yours.

Thirty days, then the working files are destroyed.

The de-identified extract and the engine's working files are destroyed within thirty days of the readout. Because the data never left your machines, your own IT performs the deletion and verifies it.

What this costs you. The verification is yours to run, and Delegate cannot attest to it. If you need evidence for an examiner, capture it when the deletion happens. There is nothing on our side to produce later.

Delegate holds no certifications and claims none.

There is no SOC 2, ISO, or other badge on this page. The protection comes from the architecture above, where institution data never enters Delegate's custody, rather than from a compliance mark.

What this costs you. If your vendor management process requires a SOC 2 report before an engagement can start, we do not have one to give you, and you should raise that early rather than at signature.

The full data specification, on request.

Every column, its type, its permitted values, and the extraction script itself are available before you commit to anything. A diligence team is welcome to read the script line by line and run its self-test against a synthetic export of your own making.

Ask for the data specification