What's in the SEC Auto ABS Loan-Level Schema

The SEC has required auto ABS issuers to publish loan-level data since 2014. In the current ABS XML Technical Specification for auto loans, ABS v3.1 dated September 18, 2023, the auto-loan XSD defines 72 asset-level data elements. If you are searching for exact ABS-EE variable names like obligorCreditScore, paymentToIncomePercentage, vehicleManufacturerName, reportingPeriodActualEndBalanceAmount, currentDelinquencyStatus, or chargedoffPrincipalAmount, those are the names that appear in the SEC schema and sample XML.

The data exists. Getting it into a form you can actually use is another matter entirely.

That work — across the issuer shelves we track — took years to get right. The result is 45.8 million unique loans, 1.14 billion monthly performance rows, and roughly 74 billion individual data points, cleaned, resolved, and ready to query. LoanTape keeps the SEC variable names visible and also maps them into query-friendly aliases where that makes analysis easier, but this post uses the SEC names first.

What Regulation AB-II actually requires

The SEC's Regulation AB-II, finalized in 2014, was designed to fix a specific problem: investors in ABS couldn't see what they owned. They got pool-level summaries (weighted-average FICO, aggregate delinquency rate, monthly loss) but no visibility into individual loans or the composition of the collateral they were exposed to.

The regulation solved this with two new filing types for every monthly reporting period:

• Form 10-D: covers the distribution period at the pool level (cash flows, credit enhancement triggers, collateral performance)
• ABS-EE: the loan-level exhibit, filed alongside the 10-D, with one row per loan per reporting period

The ABS-EE is where the data lives. Every issuer on a public ABS shelf is required to file it monthly in XML format, to a standardized schema the SEC publishes. In the current SEC auto-loan XSD, that means 72 asset-level elements spanning origination data like obligorCreditScore, vehicle fields like vehicleManufacturerName, month-end performance fields like currentDelinquencyStatus and reportingPeriodActualEndBalanceAmount, cash fields like totalActualAmountPaid, and lifecycle fields like zeroBalanceCode.

The SEC's intent was transparency. What it produced, from a data engineering standpoint, was a distributed archive: hundreds of XML files per month, one per trust, across dozens of issuers, going back over a decade.

What "just downloading it from EDGAR" actually looks like

This is where most institutional data projects quietly stall.

Each issuer has multiple trusts. Toyota alone has issued over 30 auto trust series since 2016. Santander has issued more. Every trust files its own ABS-EE XML every month, independently. To get a complete picture of one issuer's portfolio, you're looking at dozens of XML files per month. For 18 issuers over 9+ years, that's thousands of files just to get started.

The XML isn't trivial to parse. The Reg AB-II schema is well-defined, but real-world filings aren't always clean. Fields are sometimes missing, sometimes null where they shouldn't be, and the spec allows issuers to amend prior filings, which means the same loan can appear with different values across different accession numbers.

Then there's the cross-issuer normalization problem. Even within the same schema, field semantics drift. One issuer reports vehicleValueSourceCode consistently; another leaves it blank for half their trusts. The currentDelinquencyStatus buckets are standardized, but how issuers apply them varies slightly at the edges. None of this is obvious until you're deep in the data.

And then there's infrastructure: you need somewhere to store a billion rows of monthly data, tooling to keep it current as new filings drop, and a process for detecting when a prior-period amendment changes historical values.

We built all of that. It took years and it's still running.

The issuers

We currently cover the following issuer families and shelves under Regulation AB-II:

Between the captive finance arms (Toyota, Ford, Honda, Hyundai, BMW, Mercedes, Nissan, VW, Harley), the bank issuers (Ally, Capital One, Fifth Third, World Omni), and the non-prime lenders (Santander, Exeter, Drive, Bridgecrest, Carvana), you get a full cross-section of the market. Two additional issuers, California Republic and USAA, are in our config but disabled after their shelves wound down.

The field inventory

The current SEC auto-loan XSD is better understood as one asset-level schema than as a clean static-versus-monthly split. Some elements are origination-oriented, some are reporting-period measures, and some capture servicing, repurchase, and repo lifecycle events. Below, I use the exact SEC variable names because that is what issuers file and what searchers usually type into Google.

Origination-oriented SEC variables

On the borrower side, the variables most people search for are obligorCreditScore, obligorCreditScoreType, obligorEmploymentVerificationCode, obligorIncomeVerificationLevelCode, coObligorIndicator, paymentToIncomePercentage, and obligorGeographicLocation.

For the vehicle, the official SEC names are vehicleManufacturerName, vehicleModelName, vehicleModelYear, vehicleTypeCode, vehicleNewUsedCode, vehicleValueAmount, and vehicleValueSourceCode.

Loan terms and setup fields include originalLoanAmount, originalLoanTerm, originationDate, loanMaturityDate, originalInterestRatePercentage, originalInterestRateTypeCode, interestCalculationTypeCode, originalFirstPaymentDate, paymentTypeCode, underwritingIndicator, and subvented.

Some data buyers search for loanToValueRatio, originalLoanToValueRatio, leaseIndicator, or residualValueAmount. Those are not official element names in the current SEC auto-loan XSD. In LoanTape, LTV is a normalized or derived field built from raw SEC fields such as originalLoanAmount and vehicleValueAmount, while lease residual fields belong to the auto-lease schema, not the auto-loan schema.

Reporting-period SEC variables

Performance fields are reported once per loan per reporting period. A loan originated in 2020 with a 60-month term has 60 rows of monthly data, one for every month it was active. Across 45.8 million loans, that's where the 1.14 billion rows come from.

Each month starts with balance and delinquency status: reportingPeriodBeginningLoanBalanceAmount, reportingPeriodActualEndBalanceAmount, currentDelinquencyStatus, remainingTermToMaturityNumber, reportingPeriodInterestRatePercentage, and nextInterestRatePercentage.

One of the more useful parts of the spec is actual cash collected, reported separately from scheduled: totalActualAmountPaid, actualPrincipalCollectedAmount, actualInterestCollectedAmount, actualOtherCollectedAmount, scheduledPrincipalAmount, scheduledInterestAmount, reportingPeriodScheduledPaymentAmount, and nextReportingPeriodPaymentAmountDue. The gap between scheduled and actual tells you a lot about a pool before the delinquency buckets even move.

Loss and workout fields in the current auto-loan XSD are narrower than many people expect: chargedoffPrincipalAmount, recoveredAmount, repossessedIndicator, repossessedProceedsAmount, zeroBalanceCode, and zeroBalanceEffectiveDate carry most of the lifecycle signal. The current auto-loan schema does not define separate elements named chargeoffDate, chargeoffAmount, liquidationAmount, deficiencyBalanceAmount, or bankruptcyIndicator.

Modification tracking centers on reportingPeriodModificationIndicator, modificationTypeCode, and paymentExtendedNumber. The SEC added a Forbearance enumerated value to modificationTypeCode in ABS v3.1, but the current auto-loan schema does not publish standalone forbearanceIndicator, defermentIndicator, extensionIndicator, or skipPaymentIndicator elements.

Servicing and repurchase fields include servicingAdvanceMethodCode, servicingFeePercentage, servicingFlatFeeAmount, otherServicerFeeRetainedByServicer, otherAssessedUncollectedServicerFeeAmount, servicerAdvancedAmount, primaryLoanServicerName, gracePeriodNumber, assetSubjectDemandIndicator, assetSubjectDemandStatusCode, repurchaseAmount, demandResolutionDate, repurchaserName, and repurchaseReplacementReasonCode.

Across the full SEC auto-loan XSD, that comes to 72 data elements in the current schema.

The restated-field problem

The Reg AB-II spec permits issuers to amend fields after origination: a restated obligorCreditScore, a corrected vehicleValueAmount, an updated originationDate. Over a trust's life, the same loan can appear with different values across different accession numbers, all for what should be a fixed attribute.

This is not a rare edge case. We see it regularly, particularly for obligorCreditScore, vehicleValueAmount, and originationDate. The raw data has no built-in resolution mechanism. If you're joining on the latest filing, you might be using an amended value from a filing that also amended other fields inconsistently.

For every field with documented resolution logic, we track the resolved value, the resolution mode (earliest non-null, last reported, majority, etc.), the source accession number, and the filing date it came from. Every number in the dataset traces to a specific SEC filing. When someone asks where a number came from, we can answer.

The numbers

Some loans paid off in 24 months. Subprime paper regularly runs to 72 or 84. Every monthly filing cycle adds tens of millions of new rows.

What you can do with it

Vintage curves are the starting point for most credit work. originationDate, originalLoanAmount, and monthly chargedoffPrincipalAmount are all there, so you can build cumulative loss curves by issuer, vintage year, FICO band, vehicle segment, or whatever cut you need. We pre-aggregate this so you're not writing the SQL from scratch.

Roll rates and cure rates come from joining consecutive months on currentDelinquencyStatus. You get the full Markov transition matrix: what percentage of current loans stay current, how many 30-day loans cure, how many roll to 60. The below-prime version of that analysis is published on the dataset page.

The modification fields are where a lot gets missed. 2020 made this obvious: loans tagged through reportingPeriodModificationIndicator and modificationTypeCode behaved differently from unmodified loans in the same delinquency bucket. Pool-level data gives you one number. This gives you both.

Collateral cuts use vehicleManufacturerName, vehicleModelYear, and vehicleValueAmount, plus LoanTape-derived LTV fields built from official SEC inputs. Used-vehicle loans above 120% LTV have a different loss profile than new-vehicle loans below 90%. You can verify it and segment on it.

For cash flow verification: actual principal and interest collected at the loan level are reported each month. Sum by pool, reconcile against the 10-D distribution figures. When they don't match, the loan-level data tells you where to look.

Common SEC variable names

The full SEC auto-loan XSD has 72 elements. These are the ones people most often search for, with the exact SEC names first and LoanTape aliases or notes in the last column.

Borrower, vehicle, and origination variables

Reporting-period balance, cash, and credit-performance variables

Lifecycle, servicing, repo, and repurchase variables

Common search terms that are not official SEC auto-loan variables

These terms are common in Google searches and data conversations, but they are not element names in the current SEC auto-loan XSD: loanToValueRatio, originalLoanToValueRatio, chargeoffDate, chargeoffAmount, cumulativeRecoveriesAmount, forbearanceIndicator, defermentIndicator, extensionIndicator, skipPaymentIndicator, leaseIndicator, residualValueAmount, balloonIndicator, interestOnlyIndicator, prepaymentPenaltyIndicator, and nextPaymentDueDate.

Access

The ABS-EE subscription includes the current SEC auto-loan variables, plus LoanTape's normalized aliases and derived fields built on top of them. That means you can search by official names like obligorCreditScore and reportingPeriodActualEndBalanceAmount, then still work with cleaner analysis fields once you are inside the product. The monthly performance series and related trust-level cash flow products are available through the ABS remittance data product. Both are queryable via API or Databricks-compatible exports.

If you've looked at building this yourself and decided the engineering cost isn't worth it, that's probably the right call. The raw filing infrastructure exists, the XML is public, and the schema is documented. But the pipeline to turn it into something you can actually query takes years to build and needs to keep running every month. That's what you're paying for.

Pricing is at /pricing. The dataset page has the full field catalog with coverage rates by issuer.