The Otto platform

Exchange — the placement file gateway

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.

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 failure shown in this build is exactly that pair — a missing itemization date and a non-numeric balance. 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.

How does credit furnishing fit into this?

It runs off the same record rather than off a separate extract. The furnishing file is a Metro 2 file 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 the furnishing file and the collection floor cannot disagree — what is being reported and what is being collected cannot drift apart.

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. The file name is no help either: placement files arrive named by year and vendor prefix rather than by system of record, so nothing outside the file says which arrangement is inside it. 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 fictional, processing is staged, and the nightly drop is a button. What is real is the shape — the file states, the quarantine behavior, 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.