# Exchange — the placement file gateway > How Otto takes client placement files in, validates field identity before loading, quarantines bad files whole, and returns events in each client's own codes. - Source: https://ottoforfirms.com/platform/data-exchange/ - Publisher: Otto — https://ottoforfirms.com - Updated: 2026-07-26 - Status: in attorney review. Served noindex and excluded from the sitemap; do not cite as settled. **In review — not indexed.** This page describes what Otto does and is readable in full. It stays out of search until it has been reviewed, because a product claim about a compliance control is a claim somebody will hold us to. [The Otto platform](https://ottoforfirms.com/platform/) Exchange is Otto's placement-file gateway. It takes each client's inbound placement, maintenance and remittance files, validates field identity before loading anything, quarantines a file that does not parse cleanly instead of importing part of it, and returns status, payment and dispute events in that client's own codes and layouts. ## Key facts - A file that fails validation is quarantined whole. Nothing partially imports, and the reason is recorded on the file — the seeded failure is a missing itemization date and a non-numeric balance. - Event-code translation is per client and happens as the event occurs: one Otto event becomes a fixed-width position for one client, an EDI code for another, a delimited token for a third. - Outbound return files are tracked to acknowledgement, with an explicit ACK-overdue state rather than silence. - Credit furnishing runs from the same record — a Metro 2 file and the bureau dispute cases with their response clocks — and tradelines suppress on a bankruptcy or dispute hold, so the furnishing file and the collection floor cannot disagree. - Placement files arrive named by year and vendor prefix rather than by system of record, and the first field may be a name or an account number. Field identity is validated before load precisely because that ambiguity is the risk. - The shipped implementation is a simulation over seeded files against a fixed date. There is no live connection to any bank in this build. ## What arrives, and what goes back? In: placement files opening new accounts, maintenance files changing existing ones, and remittance or payment files. Out: a return file per client per cycle carrying status changes, payments posted and disputes received, in the client's own format. The inbound side shows each file with its client, record count, receipt time and status; the outbound side shows the transmission log and a preview of the file about to go, so somebody can look at the actual line before it leaves rather than after the client rejects it. ## What happens to a bad file? It is quarantined whole, and nothing from it is imported. The alternative — importing the good rows and reporting the bad ones — is how a portfolio ends up with accounts whose itemization date is blank and whose balance came from a field that said N slash A, which is a problem that surfaces months later in an exam sample rather than at two in the morning when the file landed. The quarantine records what failed and on which record, and the remedy is to re-request the file from the forwarder. Bad files get caught at the gateway or they get caught in a bank audit. ## Why does event-code translation matter? Because every client speaks a different dialect of the same events, and the firm is the one that has to be fluent in all of them. A call attempt that connects is a two-letter code at a fixed byte position for one client, a numbered code in an EDI segment for another, and a delimited token for a third. Otto records the event once and translates per client at the moment it happens, rather than in a nightly batch somebody babysits. TODO: verify how many client layouts are actually maintained in the shipped configuration before this page repeats any figure from the demonstration screen. ## How does credit furnishing fit into this? It runs off the same record rather than off a separate extract. The furnishing file is generated on a monthly cycle with the count of accounts furnished and the bureaus' acceptance recorded against it. Bureau-originated disputes arrive as cases with a received date and a response due date, linked to the account and, where relevant, to the written dispute that arrived by mail on the same facts. The rule that makes this worth doing in one system is suppression: a bankruptcy stay or a dispute hold suppresses the tradeline automatically, so what is being reported and what is being collected cannot drift apart. TODO: verify the bureau dispute response period and the suppression obligation against primary text before publication. ## Why validate field identity rather than just field format? Because the failure that hurts is not a malformed date. It is a file whose first column is a name in one delivery and an account number in the next, loaded successfully into a system that assumed the first arrangement. Format validation passes; the portfolio is now wrong in a way nothing downstream will notice. Otto checks what each field is before it loads, normalises raw phone numbers on the way in, and refuses the file when identity does not resolve. ## Is this connected to a real bank feed? No. This build simulates the gateway: files are seeded, processing is staged, and the nightly drop is a button. What is real is the shape — the file states, the quarantine behaviour, the acknowledgement tracking, the return-file preview and the translation model. Read it as a specification of how the gateway behaves, not as evidence that it has run against a production placement feed. --- This page describes Otto, not the law, and is not legal advice. Otto applies rules that have been written down correctly; it does not warrant that using it results in compliance with any statute, regulation or contract. Where a rule is named here, confirm it against the primary source and your own counsel before relying on it.