The loan tape: whether your book is legible to anyone else

A loan tape is a loan-level export of a book: 1 row per loan, carrying the terms, the balances, the payment history and the current state, in whatever template the party asking for it uses. It exists because nobody outside your company can read your database, and every transaction involving the book — a sale, a warehouse line, a servicing transfer, an audit — starts with somebody asking for the tape and forming a first impression of the lender from how it arrives.

The engineering point comes before the field list. A tape is a set of as-of questions: what was the balance on 31 March, how many days past due at each month end, when did this loan first breach 90. A servicing model storing current status answers none of them without reconstruction, and reconstruction is where 2 tapes of one book start to disagree.

Who asks for one, and what each is trying to prove

• A buyer in diligence. Testing whether performance matches what you said, and sampling 30 or 50 files against the tape to see whether the data is real.
• A warehouse or forward-flow lender. Testing eligibility line by line against the facility criteria, then re-testing every reporting period.
• A structuring or rating exercise. Needing consistent history, where a definition changed 8 months ago and backdated is worse than one that was always crude.
• Your own board and auditors. The tape is checked against the general ledger, and the two must reconcile to the cent.
• An incoming servicer. They board your loans from this file, which makes every schedule field an operational instruction rather than a report.

Six families, and where each one comes from

• Identity. Loan id, borrower id, product, origination channel, and identifiers that let a buyer join to their own systems without exposing more personal data than the stage requires.
• Terms as contracted. Principal advanced, rate and rate type, index and margin, tenure, fees capitalised, and the disbursement date as distinct from the value date.
• Schedule and current position. Instalment amount, frequency, next due date, principal outstanding, accrued interest, fees and capitalised arrears — each separately, because a single amount outstanding is unusable to anyone who did not build it.
• Performance history. Instalments due, paid and missed by period, with collection attempt outcomes beside them. A failed direct debit is not a borrower decision, and a tape merging the two hides it — see what a decline response is actually telling you.
• Origination decision data. Score, band and the affordability ratios computed at decision — comparable across a book only if the definition was pinned, the problem in your computed ratio and the underwriter's number.
• Collateral and status transitions. Security type, valuation with its date and basis, and every state change with its effective date: bucket entries, restructures, forbearance, legal action, charge-off, recovery, closure.

The fields that are computed at export time, and therefore disagree

Store transitions, not current status

The design that makes tapes cheap is unglamorous: every status a loan holds is a row with an effective-from date, an effective-to date and the event that caused it, and current status is a query rather than a column. Balances follow the same rule — postings with value dates, not a running figure updated in place. A tape as of any date is then a filter, the same code path every month, and a buyer's recut lands where yours did.

It is the same reproducibility argument that applies at the other end of the lifecycle, where decline reason codes recorded at the moment of decision cannot be rebuilt later from data that has since moved. Retrofitting effective dating onto a live book means deciding what history you are prepared to assert, and the honest answer is less than you would like — which makes this a product build decision for week 2, inside lending and credit operations, part of the finance systems we build.

• lending
• portfolio data
• servicing
• data modelling