The Form ABS-EE Files Dataset is the parsed, accession-level archive of every Form ABS-EE and Form ABS-EE/A submission filed on EDGAR — the SEC's structured asset-level disclosure form for registered asset-backed securities under Regulation AB II. One record is one EDGAR submission identified by a single accession number, bundling a parsed metadata.json header, the ABS-EE cover document, the EX-102 Asset Data File carrying the Schedule AL XML payload, and (where present) the EX-103 Asset Related Document. Filings are made by the issuing entity of a registered ABS transaction across five eligible asset classes — residential mortgages, commercial mortgages, auto loans, auto leases, and debt securities — on each distribution period of the trust. The dataset begins on the November 23, 2016 effective date of Regulation AB II's asset-level disclosure regime and is delivered as monthly ZIP containers of HTML, XML, and JSON files.
Programmatically retrieve the full list of dataset archive files, download URLs and dataset metadata.
Dataset Index JSON API
Download the entire dataset as a single archive file.
Download Entire Dataset:
Download a single container file (e.g. monthly archive) from the dataset.
Download Single Container:
The dataset captures the full population of Form ABS-EE and Form ABS-EE/A submissions on EDGAR, parsed into one accession-number folder per filing. Each accession folder is named with the eighteen-digit zero-padded EDGAR accession with hyphens stripped (for example 000092963826001373 for accession 0000929638-26-001373) and contains the four logical components of the submission: the EDGAR header parsed into metadata.json, the ABS-EE cover document, the EX-102 Asset Data File (Schedule AL XML), and — where the issuer provides one — the EX-103 Asset Related Document. Records map one-to-one to EDGAR filings, with exactly one accession folder per ABS-EE or ABS-EE/A submission.
Form ABS-EE itself is the SEC's structured asset-level disclosure form adopted under Regulation AB II (Securities Act Releases 33-9638 and 33-9639), effective November 23, 2016. It applies to issuers of registered asset-backed securities collateralized by residential mortgages, commercial mortgages, automobile loans, automobile leases, or debt securities. The form is a thin cover whose role is to identify the issuing entity and serve as the carrier for two substantive exhibits — Exhibit 102 (the Asset Data File) and Exhibit 103 (the Asset Related Document) — defined by Item 601 of Regulation S-K and populated under the Schedule AL field specifications of Item 1125 of Regulation AB. ABS-EE denotes an original asset-level disclosure for a given reporting period; ABS-EE/A denotes an amendment that supersedes or corrects a previously filed ABS-EE for the same trust and period. Amendments share the same internal anatomy as originals — only the formType value distinguishes them.
The component file types in records are HTML (the cover, wrapped in EDGAR SGML), XML (EX-102 and EX-103 on the SEC Schedule AL schemas), and JSON (metadata.json). The form has carried this same component mix since inception in November 2016 — it was introduced in the structured-XML era and never had an ASCII or pre-HTML phase. Form ABS-EE has never carried XBRL or iXBRL data; structured asset-level information lives entirely in the Schedule AL XML. The dataset is distributed as monthly ZIP containers.
One record is one EDGAR submission of Form ABS-EE or Form ABS-EE/A, identified by a single accession number. On disk, the accession-number folder bundles the parsed components of the submission: a metadata.json header file, the ABS-EE cover page, the EX-102 Asset Data File carrying the Schedule AL payload, and (where the issuer provides one) the EX-103 Asset Related Document.
Reporting cadence is periodic (typically monthly for autos and CMBS, monthly or quarterly for RMBS and debt securities), with the period end carried both in the EDGAR header (periodOfReport) and inside the EX-102 itself. The structured payload is Schedule AL XML, not XBRL or iXBRL.
The internal layout is consistent across asset classes and across original and amended filings. The four logical components are:
metadata.json — parsed EDGAR header and document role map.<DOCUMENT> SGML envelope, type = "ABS-EE".type = "EX-102".type = "EX-103".Filenames inside the folder are not standardized; each filing agent picks its own (e.g. bmw2023-a_exhibit102.xml, exh_102.xml, ex102.xml, mbalt24bex102_0414-1613.xml, FormABSEECCMT16P6.htm). The authoritative role assignment for any file is metadata.json.documentFormatFiles[].type — never a filename heuristic. The consolidated EDGAR submission .txt is referenced by documentFormatFiles but is not written to disk; only the individually parsed components are kept. Image files attached to the original submission are also excluded.
metadata.jsonThe metadata file is the canonical entry point and contains the parsed EDGAR submission header plus a manifest of attached documents. Key fields:
formType — "ABS-EE" or "ABS-EE/A".accessionNo — canonical EDGAR accession with hyphens ("0000929638-26-001373"); the on-disk folder name strips the hyphens.description — uniformly "Form ABS-EE - Asset-Backed Electronic Exhibits".filedAt — ISO-8601 timestamp with timezone offset.periodOfReport — asset-data reporting period end date (Schedule AL Item 3(b)(2) for autos, Item 2(b)(2) for CMBS).linkToFilingDetails, linkToTxt, linkToHtml — URLs back to the EDGAR filing-index page, the consolidated submission text file, and the HTML cover.documentFormatFiles[] — one entry per attached document, with sequence, size, documentUrl, description, and type. The type values are ABS-EE (cover), EX-102 (Asset Data File), EX-103 (Asset Related Document), and an empty value for the consolidated .txt. This array is the canonical map between on-disk filenames and logical roles.entities[] �� one entry per filer entity, with cik, companyName, fileNo, irsNo, act, fiscalYearEnd, stateOfIncorporation, sic (typically "6189 Asset-Backed Securities"), filmNo, and type. Multi-entity filings list both the depositor and the issuing trust.seriesAndClassesContractsInformation, dataFiles, linkToXbrl — present in the schema but uniformly empty for ABS-EE filings.The cover is the regulatory face of the filing. It is wrapped in the EDGAR <DOCUMENT> SGML envelope (<DOCUMENT><TYPE>ABS-EE<SEQUENCE>1<FILENAME>...<DESCRIPTION>FORM FOR SUBMISSION OF ELECTRONIC EXHIBITS FOR ASSET-BACKED SECURITIES<TEXT>...</TEXT></DOCUMENT>) with an HTML body inside the <TEXT> block. The HTML body identifies:
The cover carries no asset-level data and is not required for downstream analytics; its role is to identify the parties and acknowledge the substantive exhibits.
EX-102 is the substantive payload and the dominant consumer of bytes in a record. It is a single XML document with root <assetData> whose default namespace declares the asset class. The schema is the SEC's Schedule AL XML, with one schema per asset class. The five namespaces are:
http://www.sec.gov/edgar/document/absee/autoloan/assetdata — automobile loans.http://www.sec.gov/edgar/document/absee/autolease/assetdata — automobile leases.http://www.sec.gov/edgar/document/absee/cmbs/assetdata — commercial mortgage-backed securities.http://www.sec.gov/edgar/document/absee/rmbs/assetdata — residential mortgage-backed securities.http://www.sec.gov/edgar/document/absee/debtsec/assetdata — debt securities backed by debt securities.The top-level structure is uniform across asset classes: one <assets> element per asset (loan, lease, mortgage, security) in the underlying pool, repeated as siblings under the root. Auto-loan filings can hold tens of thousands of <assets> elements, with EX-102 sizes ranging from a few megabytes to roughly half a gigabyte; CMBS filings hold tens to a few hundred loans but have substantially richer per-loan substructure.
Encoding conventions inside element text:
.04050000, 75000000.00000000).MM-DD-YYYY for absolute dates and MM/YYYY for month-only fields.propertyTypeCode = "MU", paymentTypeCode = "2").true/false.Each <assets> element is a flat block of fields organized into the families enumerated in Item 3:
assetTypeNumber, assetNumber, reportingPeriodBeginningDate, reportingPeriodEndingDate.originatorName, originationDate, originalLoanAmount, originalLoanTerm, loanMaturityDate, originalInterestRatePercentage, interestCalculationTypeCode, originalInterestRateTypeCode, originalFirstPaymentDate, underwritingIndicator, gracePeriodNumber, paymentTypeCode, subvented.vehicleManufacturerName, vehicleModelName, vehicleNewUsedCode, vehicleModelYear, vehicleTypeCode, vehicleValueAmount, vehicleValueSourceCode.obligorCreditScoreType, obligorCreditScore, obligorIncomeVerificationLevelCode, obligorEmploymentVerificationCode, coObligorIndicator, paymentToIncomePercentage, obligorGeographicLocation.assetAddedIndicator, remainingTermToMaturityNumber, reportingPeriodModificationIndicator, servicingAdvanceMethodCode, reportingPeriodBeginningLoanBalanceAmount, nextReportingPeriodPaymentAmountDue, reportingPeriodInterestRatePercentage, nextInterestRatePercentage, servicingFeePercentage, servicingFlatFeeAmount, otherServicerFeeRetainedByServicer, otherAssessedUncollectedServicerFeeAmount, scheduledInterestAmount, scheduledPrincipalAmount, otherPrincipalAdjustmentAmount, reportingPeriodActualEndBalanceAmount, reportingPeriodScheduledPaymentAmount, totalActualAmountPaid, actualInterestCollectedAmount, actualPrincipalCollectedAmount, actualOtherCollectedAmount, servicerAdvancedAmount, interestPaidThroughDate, zeroBalanceEffectiveDate, zeroBalanceCode.currentDelinquencyStatus in days past due.primaryLoanServicerName, mostRecentServicingTransferReceivedDate.assetSubjectDemandIndicator, assetSubjectDemandStatusCode, repurchaseAmount, demandResolutionDate, repurchaserName, repurchaseReplacementReasonCode.chargedoffPrincipalAmount, recoveredAmount.modificationTypeCode, paymentExtendedNumber.repossessedIndicator, repossessedProceedsAmount.The auto-lease schema mirrors the auto-loan layout but substitutes lease economics for loan economics. Loan-side fields are replaced with lease-side equivalents: acquisitionCost, originalLeaseTermNumber, baseResidualValue, baseResidualSourceCode, contractResidualValue, lesseeCreditScoreType, lesseeCreditScore, lesseeIncomeVerificationLevelCode, lesseeEmploymentVerificationCode, coLesseePresentIndicator, paidThroughDate, primaryLeaseServicerName, excessFeeAmount, and liquidationProceedsAmount. The vehicle, obligor (now lessee), payment-and-performance, demand, charge-off, modification, and repossession families parallel the loan schema. The reporting-period end field uses the spelling reportingPeriodEndDate (without the trailing "ing" of the auto-loan schema).
The CMBS schema is materially richer because each securitized loan can be secured by one or more properties. Each <assets> block contains loan-level fields plus one or more nested <property> elements:
assetTypeNumber, assetNumber, optional <GroupID> (sub-pool grouping; absent in older schemas), reportingPeriodBeginningDate, reportingPeriodEndDate, originatorName, originationDate, originalLoanAmount, originalTermLoanNumber, maturityDate, originalAmortizationTermNumber, originalInterestRatePercentage, interestRateSecuritizationPercentage, interestAccrualMethodCode, originalInterestRateTypeCode, originalInterestOnlyTermNumber, firstLoanPaymentDueDate, underwritingIndicator, lienPositionSecuritizationCode, loanStructureCode, paymentTypeCode, periodicPrincipalAndInterestPaymentSecuritizationAmount, scheduledPrincipalBalanceSecuritizationAmount, paymentFrequencyCode, NumberPropertiesSecuritization, NumberProperties, graceDaysAllowedNumber, interestOnlyIndicator, balloonIndicator, prepaymentPremiumIndicator, negativeAmortizationIndicator, modifiedIndicator, prepaymentLockOutEndDate, yieldMaintenanceEndDate, prepaymentPremiumsEndDate, deferredInterestCumulativeAmount, deferredInterestCollectedAmount.<property>, Item 2(d)): propertyName, propertyAddress, propertyCity, propertyState, propertyZip, propertyCounty; propertyTypeCode mnemonics (MU mixed-use, MF multifamily, OF office, RT retail, IN industrial, LO lodging, WH warehouse, etc.); space measures (netRentableSquareFeetNumber and netRentableSquareFeetSecuritizationNumber, replaced by unitsBedsRoomsNumber / unitsBedsRoomsSecuritizationNumber for multifamily and lodging); yearBuiltNumber, yearLastRenovated; valuation block (valuationSecuritizationAmount, valuationSourceSecuritizationCode, valuationSecuritizationDate, mostRecentValuationAmount, mostRecentValuationDate, mostRecentValuationSourceCode); occupancy (physicalOccupancySecuritizationPercentage, mostRecentPhysicalOccupancyPercentage); status (propertyStatusCode, defeasanceOptionStartDate, DefeasedStatusCode); top-three-tenant block (largestTenant, squareFeetLargestTenantNumber, leaseExpirationLargestTenantDate, with secondLargestTenant and thirdLargestTenant siblings carrying their own square-feet and expiration fields); and a property-financials block (mostRecentFinancialsStartDate, mostRecentFinancialsEndDate, revenueSecuritizationAmount, mostRecentRevenueAmount, operatingExpensesSecuritizationAmount, operatingExpensesAmount, netOperatingIncomeSecuritizationAmount, mostRecentNetOperatingIncomeAmount, netCashFlowFlowSecuritizationAmount, mostRecentNetCashFlowAmount, netOperatingIncomeNetCashFlowSecuritizationCode, netOperatingIncomeNetCashFlowCode, mostRecentDebtServiceAmount, debt-service-coverage fields, mostRecentDebtServiceCoverageCode, mostRecentAnnualLeaseRolloverReviewDate).<property> children): assetAddedIndicator, reportPeriodModificationIndicator, reportPeriodBeginningScheduleLoanBalanceAmount, totalScheduledPrincipalInterestDueAmount, reportPeriodInterestRatePercentage, servicerTrusteeFeeRatePercentage, scheduledInterestAmount, scheduledPrincipalAmount, otherPrincipalAdjustmentAmount, reportPeriodEndActualBalanceAmount, reportPeriodEndScheduledLoanBalanceAmount, paidThroughDate, nonRecoverabilityIndicator, totalPrincipalInterestAdvancedOutstandingAmount, totalTaxesInsuranceAdvancesOutstandingAmount, otherExpensesAdvancedOutstandingAmount, paymentStatusLoanCode, primaryServicerName, assetSubjectDemandIndicator, prepaymentPremiumYieldMaintenanceReceivedAmount. Note that the CMBS performance block uses the prefix reportPeriod (no trailing "ing"), in contrast to the reportingPeriod prefix used in the auto schemas.RMBS filings use the absee/rmbs/assetdata namespace and populate Item 1 of Schedule AL. Each <assets> block carries: loan identification and origination terms (loan amount, term, rate type, ARM index and margin, periodic and lifetime caps and floors, origination channel, lien position, occupancy type, property type and address, original LTV / CLTV, original appraisal); borrower attributes (credit score type and value, debt-to-income, income and asset verification levels, number of borrowers, employment verification, first-time-homebuyer indicator); mortgage-insurance coverage (insurer, coverage percentage, certificate number, cancellation indicator); modification history (modification effective date, modification codes, capitalized amounts, post-modification rate and term); foreclosure / REO progression (delinquency status, foreclosure referral and sale dates, REO acquisition and disposition dates, liquidation proceeds, loss amounts); and monthly payment performance (scheduled and actual principal and interest, escrow, advances, servicing fees, prepayment indicator, paid-through date, zero-balance code and effective date).
Debt-securities filings use the absee/debtsec/assetdata namespace and replace the collateral-property block with security-level identifiers and cash-flow records. Each <assets> block carries: security identification (CUSIP-form assetNumber, issuer name, security type, par amount, coupon, maturity, payment frequency, original and current ratings); position economics (acquisition price and date, current market value); and a periodic cash-flow record of interest and principal events on each underlying security for the reporting period.
EX-103 is a short XML file whose role is purely explanatory: it documents how the issuer interprets the Schedule AL fields, what code values mean in its filing, and which fields it has chosen to omit as not applicable. It carries no asset values. Three structural patterns are in active use:
<assetdata> (or <assetData>) containing a sequence of free-form XML comments, each describing one Schedule AL item by number — for example <!--Item 3(c)(11) - Underwriting Indicator. Reported value is "true" for...-->. Common among auto-loan issuers.<commentData> pattern. Root is <comments> and each clarification is a <commentData> record with three children: <itemNumber> (e.g. Item 2(d)(8)), <fieldName> (e.g. Net Rentable Square Feet), and <comment> (the narrative). Used by several CMBS trusts and some auto issuers.<assetData> mirroring the EX-102 schema, with empty field elements each annotated by an inline XML comment that documents field-level conventions.EX-103 is not required to mechanically parse the EX-102, but it is required to interpret issuer-specific code values, threshold conventions, and intentional omissions correctly. Consumers cannot assume a single root element.
A record includes:
metadata.json.<DOCUMENT> envelope.<property> sub-blocks for CMBS/RMBS, and any <GroupID> sub-pool identifiers..txt file aggregating all attached documents — referenced by documentFormatFiles but not written to disk.The dataset begins with the November 23, 2016 effective date of Regulation AB II's asset-level disclosure regime, so the record-level anatomy has been stable across the dataset's full history. The form was created in its current shape: a thin cover plus EX-102 (Schedule AL XML) plus EX-103 (Asset Related Document). Visible evolutions:
<GroupID> child immediately after <assetNumber> to identify sub-pool groupings; older CMBS schemas omit it. Auto-loan and auto-lease schemas have been more stable.reportingPeriodEndingDate, auto-lease and CMBS use reportingPeriodEndDate, and the CMBS performance block drops the "ing" entirely (reportPeriodEndActualBalanceAmount, reportPeriodBeginningScheduleLoanBalanceAmount). These differences are stable within an asset class and reflect the original Schedule AL XML specifications.<comments>/<commentData> form has become more common over time, particularly among CMBS trustees, but no SEC mandate prescribes a single shape.metadata.json. Filenames inside an accession folder are not standardized; filing-agent conventions vary widely. Always identify the cover, EX-102, and EX-103 via documentFormatFiles[].type.<assets> element counts in the tens of thousands. SAX or StAX parsing is required; tree-loading DOM parsers will exhaust memory. CMBS EX-102 files are smaller in element count but still benefit from streaming because of the nested <property> substructure.reportingPeriodEndingDate (auto-loan) and reportingPeriodEndDate (auto-lease, CMBS), and the CMBS performance-block forms that drop the "ing" (reportPeriodEndActualBalanceAmount, reportPeriodBeginningScheduleLoanBalanceAmount)..04050000). Booleans are lowercase true/false. Many text fields carry significant trailing whitespace and should be trimmed before comparison.<property> children inside one <assets> element; the loan-level NumberProperties and NumberPropertiesSecuritization fields advertise the count and should agree with the child-element count.<assetdata> with comment children, <comments> with <commentData> records, and <assetData> skeletons with empty fields and per-field comments). Code cannot assume a single root element.metadata.json.entities may carry both the depositor and the issuing trust as separate entries, each with its own CIK, file number, and sic. Records keyed solely by the issuing trust will lose the depositor relationship; both entries should be retained for lineage analysis.ABS-EE/A records are anatomically identical to ABS-EE and supersede the prior submission for the same trust and reporting period. Workflows that compute the latest authoritative pool snapshot should select on formType, entities[].cik, and periodOfReport and prefer the most recent filedAt.Form ABS-EE is filed by the issuing entity of a registered asset-backed securities transaction (the trust or other special-purpose vehicle holding the receivables). The depositor, typically a wholly owned subsidiary of the sponsor, signs as the issuing entity's authorized representative, mirroring how it signs the trust's other Exchange Act periodic reports. The submission is made under the issuing entity's EDGAR CIK.
The filer population is limited to issuers of registered ABS whose pool collateral falls within the five asset classes for which the SEC adopted Schedule AL line items in Regulation AB II:
Issuers of registered ABS backed by other collateral (credit cards, student loans, equipment leases, dealer floorplan) remain subject to Regulation AB II's other reforms but do not file Form ABS-EE. Private ABS offerings (Rule 144A, Section 4(a)(2), Reg D) are entirely outside the regime.
The obligation is periodic and distribution-driven. Asset-level disclosure under Item 1125 of Regulation AB (17 CFR 229.1125) must be made for each distribution period of the issuing entity, as defined in the pooling and servicing or indenture documents. In practice this is monthly for nearly all RMBS, auto, and debt-security transactions, and monthly or quarterly for CMBS.
Form ABS-EE must be filed on or before the corresponding Form 10-D distribution report, and its EX-102 Schedule AL XML payload is incorporated by reference into that 10-D. Form 10-D is itself due within 15 days after each distribution date, so ABS-EE is typically filed the same day as the 10-D for the same period. Each filing carries asset-level data as of the servicer's cut-off date covering origination characteristics, scheduled and actual payments, delinquency, modifications, prepayments, charge-offs, and performance for each loan or asset (or each underlying security in a resecuritization).
A Form ABS-EE/A amendment is triggered after the fact when the issuing entity needs to correct previously filed asset-level data: restating field values, adding omitted assets, fixing XML schema errors, or reflecting post-period adjustments by the servicer or trustee. The amendment references the original ABS-EE by distribution period and supersedes or supplements the prior Schedule AL XML; corrections are not rolled silently into the next period's filing.
The asset-level regime was adopted in Release Nos. 33-9638; 34-72982 (Asset-Backed Securities Disclosure and Registration), the 2014 rulemaking commonly known as Regulation AB II. The Schedule AL requirement under Item 1125 (and the broader pool-disclosure framework under Item 1124) became effective for offerings on November 23, 2016, which is also the earliest date Form ABS-EE filings appear on EDGAR. Form ABS-EE was created by Regulation AB II and exists only as an electronic XML-bearing EDGAR submission; there is no pre-2016 analog.
The Form SF-3 shelf-eligibility tie is structural. Continued use of Form SF-3 for registered ABS shelf takedowns conditions on timely filing of Exchange Act reports, including Form 10-D and Form ABS-EE, for all transactions of the same depositor (or its affiliates) in the prior twelve months. A late or missed ABS-EE can therefore impair the depositor's shelf eligibility for new registered offerings.
The boundary that matters is between standardized asset-level data (ABS-EE / EX-102) and every other ABS disclosure, which is pool-level, narrative, transactional, or registration-oriented.
Form 10-D — Asset-Backed Distribution Report. Same filer (issuing entity) and same distribution-period cadence as ABS-EE; in practice paired with the same cycle. Difference is granularity: 10-D carries the pool-level distribution report, servicer data, and Item 1121 narrative in HTML. ABS-EE carries the loan-level XML payload behind those aggregates. Use 10-D for trust-level performance and material events; use ABS-EE for loan-level transitions, prepayments, and collateral cuts. Complementary, not substitutable.
Form ABS-15G (Rules 15Ga-1 and 15Ga-2). Filed by securitizers, sponsors, or depositors, not the issuing entity. Two streams: 15Ga-1 quarterly/annual repurchase history for rep-and-warranty claims, and 15Ga-2 transaction-triggered findings from third-party pre-issuance due diligence. Cadence is quarterly/annual or deal-triggered. Content does not overlap ABS-EE: 15G addresses origination quality and repurchase enforcement; ABS-EE addresses ongoing asset performance. Together they triangulate origination diligence (15Ga-2), realized performance (ABS-EE), and repurchase outcomes (15Ga-1).
Form 10-K, Items 1122 and 1123. ABS 10-Ks are narrow, centered on Item 1122 servicing-criteria compliance, Item 1123 servicer compliance statements, and accountant attestation. Annual, process-focused. ABS-EE answers "how is each loan performing"; 1122/1123 answer "did the servicer follow defined criteria over the year."
Form SF-3 — Shelf Registration. Transaction-stage registration adopted under Reg AB II, containing pool descriptions, structure, risk factors, and depositor certifications. Current ABS-EE reporting is a condition of continued SF-3 shelf eligibility, but SF-3 itself contains no periodic asset data.
Form SF-1 — Non-Shelf Registration. Non-shelf counterpart to SF-3 for one-off registered ABS offerings. Like SF-1, it is registration-time prospectus content; it does not generate the recurring monthly XML stream that ABS-EE produces.
Schedule AL (Item 1125 of Reg AB) vs. EX-102. Schedule AL is the rule listing required data points by asset class. EX-102 is the XML exhibit inside an ABS-EE filing that implements Schedule AL for a specific period and trust. This dataset contains EX-102 instances, not the specification.
EX-102 vs. EX-103 within an ABS-EE filing. EX-102 is the structured Asset Data File (Schedule AL XML), machine-readable and suitable for panel analytics. EX-103 is the Asset Related Document, an unstructured supplement (definitions, exceptions, pool-specific context) typically requiring text or PDF parsing. Anchor loan-performance work on EX-102; consult EX-103 for footnote-style context.
Fannie Mae and Freddie Mac single-family and multifamily loan-level historical datasets, the FFIEC HMDA Loan/Application Register, and private RMBS/CMBS investor reporting packages from trustees or data vendors all expose loan-level fields. None are filed under Reg AB II, none use Schedule AL field definitions, and none reside on EDGAR. Coverage, schema, asset-class scope, and access mechanisms differ. ABS-EE is the only SEC-mandated, EDGAR-resident, standardized loan-level XML disclosure for registered ABS in the five covered asset classes.
ABS-EE is uniquely defined by:
No other SEC dataset substitutes for ABS-EE when the question is asset- or loan-level. Surrounding forms describe the trust, servicer, sponsor, or offering; ABS-EE is the only one that describes each underlying asset.
Users of the Form ABS-EE Files Dataset are concentrated in structured finance and split by which Schedule AL field families and time cuts they consume.
Portfolio managers and credit analysts on RMBS, CMBS, auto-ABS, and equipment-ABS desks at structured-credit hedge funds, fixed-income asset managers, insurance general accounts, and ABS-holding REITs use Schedule AL as the bond-level fundamental input.
Structuring bankers pull historical Schedule AL from comparable shelves to build stratifications, vintage curves, and collateral benchmarks for prospectus supplements and investor decks. Trading desks use origination characteristics, current balance, scheduled vs. actual payment, delinquency bucket, prepayment indicator, and charge-off / loss amounts to mark CUSIPs, respond to BWICs, and post axes grounded in actual collateral trends.
Sell-side and independent research analysts aggregate Schedule AL across deals to publish 30/60/90 delinquency, roll rates, CDR, CPR, severity, modification incidence, and recovery lag by sector, vintage, originator, servicer, and geography. Loan-level granularity supports cuts by FICO band, LTV band, loan purpose, vehicle segment, or obligor industry.
New-issue analysts feed issuance-period stratifications into cash-flow models and stress scenarios to assign initial tranche ratings. Surveillance analysts ingest monthly EX-102 updates to refresh loss expectations, run rating-migration analyses, place tranches on watch, and document committee actions. Focus fields: delinquency status, modification flags, charge-off amounts, recovery proceeds, repossession status, and any covariate for default and severity vectors.
Quantitative researchers build prepayment, default, transition, and severity models using the loan-level panel (loan ID across reporting periods) for hazard and competing-risks estimation. Origination fields serve as covariates, payment-status transitions as state variables, modification flags as treatment indicators, and charge-off / liquidation-proceeds fields for severity distributions. Outputs feed CPR/CDR vectors into proprietary or third-party cash-flow engines, scenario generators, and roll-rate ML models that drive pricing, OAS, and tranche-loss projections.
Market-risk, credit-risk, and ALM teams at banks, broker-dealers, insurers, and pension funds holding ABS use Schedule AL for independent price verification, internal credit review, and regulatory capital workflows including stress testing and look-through frameworks. They reconcile vendor marks against models built on collateral data, document assumptions for model-risk review, and monitor concentration by originator, servicer, geography, or obligor segment. Key fields: current balance, delinquency status, modification status, charge-off amounts, supporting expected-loss and lifetime-loss estimates.
Counsel for issuers, depositors, and underwriters, plus Reg AB II compliance officers, verify that filings meet Item 1125 and Schedule AL requirements: completeness of required fields, presence of EX-103 Asset Related Documents, proper use of ABS-EE/A amendments, and treatment of optional or sensitive fields (obligor geography, originator identification). The workflow supports disclosure-controls testing, peer benchmarking, and responses to SEC staff comment letters.
Servicing operations and trustee surveillance teams reconcile reported loan-level current balances, payment status, modification flags, and charge-off entries across EX-102 data, monthly distribution reports, and internal loan-accounting systems, surfacing breaks that signal mapping errors or restatement risk. The data also benchmarks reporting practices against peer servicers on similar collateral.
Financial regulator and central bank staff monitor sector-wide delinquency, prepayment, modification, and originator-level performance for systemic surveillance. Academic researchers use the loan-level panel from November 2016 onward to study underwriting standards and default, modification policy effects, and the price of structured credit risk, leveraging consistent Schedule AL definitions across deals.
Structured-finance data vendors and benchmark-index providers ingest EX-102 XML, normalize Schedule AL into vendor schemas, map loan IDs across periods, attach deal and tranche identifiers, and republish loan-level histories with computed CPR, CDR, roll rates, and severity. Index providers use the data for performance indices and constituent-eligibility checks based on collateral characteristics.
Distressed and special-situations investors evaluating non-performing pools, residual tranches, and call-rights opportunities use liquidation-proceeds, recovery-timing, repossession-status, and modification-history fields to model residual cash flows, optimal-redemption economics, and bottom-up recoveries on charged-off or repossessed assets.
Engineering teams build parsers for Schedule AL XML, ground LLM responses in loan-level facts, and develop agents that answer queries such as "how have 60+ delinquencies in this shelf evolved over the last twelve reporting periods." The standardized schema enables structured extraction and joins to related SEC filings (424B prospectuses, 10-D distribution reports, 8-K notices).
The common thread across all of these users is moving past pool-level summaries to Schedule AL records, where origination, payment, delinquency, modification, charge-off, and recovery fields drive cash-flow models, surveillance, rating actions, risk metrics, and disclosure review.
The use cases below describe concrete operations on EX-102 Schedule AL XML, EX-103 footnotes, and metadata.json headers across one or more accession folders.
A structured-credit quant at an asset manager streams every auto-loan EX-102 (absee/autoloan/assetdata namespace) for a target shelf with a SAX parser, keying each <assets> element by assetNumber across reportingPeriodEndingDate snapshots. Origination fields (originationDate, originalLoanAmount, originalInterestRatePercentage, obligorCreditScore, paymentToIncomePercentage, vehicleNewUsedCode) become covariates; currentDelinquencyStatus, zeroBalanceCode, chargedoffPrincipalAmount, and recoveredAmount define hazard states. The output is a refreshed CPR/CDR/severity vector fed into the firm's cash-flow engine for OAS pricing and tranche-loss projections.
A CMBS surveillance analyst at a rating agency parses each monthly CMBS EX-102 (absee/cmbs/assetdata) and walks the nested <property> blocks for every <assets> loan. The analyst tracks largestTenant / secondLargestTenant / thirdLargestTenant with their squareFeetLargestTenantNumber and leaseExpirationLargestTenantDate, joined to mostRecentNetOperatingIncomeAmount, mostRecentDebtServiceAmount, physicalOccupancySecuritizationPercentage, and paymentStatusLoanCode. Migration in DSCR or rollover risk on top tenants drives watchlist additions, rating-committee memos, and tranche placements on negative outlook.
An ABS data-vendor pipeline groups records by entities[].cik (issuing trust), periodOfReport, and formType, then selects the most recent filedAt so that any ABS-EE/A supersedes the prior ABS-EE for the same trust-period. The vendor republishes a single authoritative loan-level history with stable assetNumber keys, computed CPR/CDR/roll rates, and audit links back to the corrected accession. Downstream subscribers consume the cleaned panel without having to deduplicate amendments themselves.
A portfolio manager at a structured-credit hedge fund pulls each new monthly EX-102 for held auto-ABS and RMBS shelves, buckets currentDelinquencyStatus (auto) or RMBS delinquency / foreclosure-progression fields into 30/60/90+ buckets, and computes roll rates against the prior month's snapshot keyed on assetNumber. When 60+ migration breaches a deal trigger or step-down test, the system fires an alert, attaches a reconciliation against the trustee 10-D, and produces a hold/sell/swap recommendation backed by the loan-level cuts.
A fintech quant team aggregates RMBS EX-102 across the full November 2016 panel, joining origination attributes (FICO, original LTV/CLTV, DTI, occupancy, lien position, doc level) to monthly performance and the foreclosure / REO progression block (referral and sale dates, REO acquisition and disposition dates, liquidation proceeds, loss amounts). The output is a labeled hazard / competing-risks training set for gradient-boosted default and severity models that downstream feed credit-risk transfer pricing and ABS relative-value screens.
A securities lawyer for an auto-ABS depositor walks each filed accession folder via metadata.json.documentFormatFiles[], confirms the presence of an EX-102 and (where required) an EX-103, and validates that every Schedule AL Item 3 family (origination, vehicle, obligor, payment-and-performance, demand, charge-off, modification, repossession) is populated for each <assets> block. Intentional omissions are cross-checked against the EX-103 comment-list or <commentData> records. The workflow produces a disclosure-controls memo and a remediation list of fields to address before the next monthly filing.
A master-servicer surveillance team sums reportingPeriodActualEndBalanceAmount (auto), reportPeriodEndActualBalanceAmount (CMBS), and actualPrincipalCollectedAmount / actualInterestCollectedAmount across all <assets> in EX-102, then reconciles against the trust-level totals on the matching 10-D distribution report. Variance beyond tolerance flags servicer mapping errors, missing modifications, or pending restatements. The output is an exception report routed to the sub-servicer and trustee for correction prior to the next reporting cycle.
A sell-side structuring banker pulls EX-102 from three to five comparable historical shelves in the same asset class, parses origination fields (originalLoanAmount, originalInterestRatePercentage, obligorCreditScore, originatorName, obligorGeographicLocation, vehicleModelYear), and produces FICO-band, LTV-band, geography, and originator stratifications plus seasoned vintage curves. The stratifications populate the Schedule AL-aligned tables and risk-factor sections of the new SF-3 prospectus supplement and back the marketing deck used in investor roadshows.
The Form ABS-EE Files Dataset can be accessed in three ways: through the dataset index JSON API for metadata and container listings, as a single full archive download, or as individual container ZIP files. Downloads require an SEC API key appended to the URL as ?token=YOUR_API_KEY.
Dataset Index JSON API: https://api.sec-api.io/datasets/form-absee-files.json
This endpoint returns dataset metadata including the dataset name, description, last updated timestamp, earliest sample date, total record count, total size, form types covered, container format, and file types included. It also returns the full dataset download URL and a containers[] array listing every container file with its key, size, records, updatedAt, and signed download URL. This endpoint does not require an API key.
The index JSON is the recommended way to monitor daily refresh runs: by inspecting each container's updatedAt timestamp, you can determine which containers changed in the most recent refresh and decide which ones to re-download incrementally.
Example response:
1
{
2
"datasetId": "1f13365b-9ae0-68fb-b13e-89f975019130",
3
"datasetDownloadUrl": "https://api.sec-api.io/datasets/form-absee-files.zip",
4
"name": "Form ABS-EE Files Dataset",
5
"updatedAt": "2026-04-25T02:51:19.000Z",
6
"earliestSampleDate": "2016-11-01",
7
"totalRecords": 128311,
8
"totalSize": 126265501920,
9
"formTypes": ["ABS-EE", "ABS-EE/A"],
10
"containerFormat": "ZIP",
11
"fileTypes": ["HTML", "XML", "JSON"],
12
"containers": [
13
{
14
"downloadUrl": "https://api.sec-api.io/datasets/form-absee-files/2026/2026-03.zip",
15
"key": "2026/2026-03.zip",
16
"size": 13818783,
17
"records": 154,
18
"updatedAt": "2026-04-25T02:51:19.000Z"
19
}
20
]
21
}
Download Entire Dataset: https://api.sec-api.io/datasets/form-absee-files.zip?token=YOUR_API_KEY
Downloads the complete dataset as a single ZIP archive covering all filings since November 2016. The full archive is the concatenation of all per-container ZIP files listed in the index JSON. This endpoint requires an API key.
Download Single Container: https://api.sec-api.io/datasets/form-absee-files/2026/2026-03.zip?token=YOUR_API_KEY
Downloads one individual monthly container instead of the full dataset. Use the downloadUrl values from the containers[] array in the index JSON to retrieve specific months. This endpoint requires an API key.
The dataset covers Form ABS-EE (original asset-level disclosure for a given reporting period) and Form ABS-EE/A (amendments that supersede or correct a previously filed ABS-EE for the same trust and period). Both form types share the same internal record anatomy and are distinguished only by the formType value in metadata.json.
One record represents one EDGAR submission of Form ABS-EE or Form ABS-EE/A, identified by a single accession number. On disk, it is an accession-number folder containing four logical components: a metadata.json header, the ABS-EE cover document (HTML in EDGAR SGML), the EX-102 Asset Data File (Schedule AL XML), and (where present) the EX-103 Asset Related Document (XML).
Form ABS-EE is filed by the issuing entity (the trust or special-purpose vehicle) of a registered asset-backed securities transaction whose pool collateral falls within five eligible asset classes: residential mortgages, commercial mortgages, auto loans, auto leases, and debt securities. The depositor signs as the issuing entity's authorized representative. Issuers of registered ABS backed by other collateral (credit cards, student loans, equipment leases, dealer floorplan) and private ABS offerings (Rule 144A, Section 4(a)(2), Reg D) do not file ABS-EE.
The obligation is periodic and distribution-driven under Item 1125 of Regulation AB. In practice this is monthly for nearly all RMBS, auto, and debt-security transactions, and monthly or quarterly for CMBS. Form ABS-EE must be filed on or before the corresponding Form 10-D distribution report, which is itself due within 15 days after each distribution date.
The dataset begins on November 23, 2016 — the effective date of Regulation AB II's asset-level disclosure regime and the earliest date Form ABS-EE filings appear on EDGAR. There is no pre-2016 history; Form ABS-EE was created by Regulation AB II and has no earlier analog.
The dataset is delivered as monthly ZIP containers. Inside each container, records are accession-number folders containing HTML (the ABS-EE cover, wrapped in EDGAR SGML), XML (EX-102 Schedule AL data and EX-103 Asset Related Document), and JSON (metadata.json). Form ABS-EE has never carried XBRL or iXBRL data; structured asset-level information lives entirely in the Schedule AL XML.
Form 10-D and Form ABS-EE share the same filer (the issuing entity) and the same distribution-period cadence, and ABS-EE is filed on or before the matching 10-D. The difference is granularity: 10-D carries the pool-level distribution report, servicer data, and Item 1121 narrative in HTML, while ABS-EE carries the loan-level Schedule AL XML payload behind those aggregates. Use 10-D for trust-level performance and material events; use ABS-EE for loan-level transitions, prepayments, and collateral cuts.