Structured finance relies on specialized systems for origination, servicing, securitization, disclosure, investor reporting, and portfolio surveillance. The challenge is that those systems rarely share the same schemas, field definitions, or reporting conventions. Servicer tapes arrive in different formats, reporting systems use different definitions, and each hand-off creates mapping and reconciliation work before the data is ready for analysis or reporting.
To see where those hand-offs break down, it helps to map the stack itself: six software layers, the artifacts that move between them, and the regulations that shape what each one has to produce.
The six layers of structured finance software
Most structured finance workflows rely on systems that fit into these categories:
The problem is simple: data created in one layer is rarely ready to use in the next.
The data hand-offs that create the most work
Four artifacts illustrate why securitization software creates so much downstream data preparation:
- Loan and servicer tapes: Asset-level and performance data whose schemas and calculations can vary by originator, servicer, transaction, and asset class.
- Waterfall and cash flow models: Transaction-specific logic that depends on clean collateral inputs. A bad field mapping can affect projections and surveillance.
- Schedule AL and Form ABS-EE: For registered U.S. ABS offerings backed by residential mortgages, commercial mortgages, auto loans, auto leases or debt securities, Schedule AL sets out standardized asset-level data: 270 data points per loan for RMBS, 152 for CMBS, 72 for auto loans, filed in XML as Exhibit 102 to Form ABS-EE at offering and again with each Form 10-D.
- Remittance and investor reports: Periodic performance data that often must be reconciled with upstream servicing information before analysts can trust it.
Regulation adds another layer. Reg AB II governs asset-level disclosure for registered U.S. ABS offerings in five asset classes, which in practice means auto ABS and CMBS: no private-label RMBS deal has been SEC-registered since the rule took effect, so RMBS disclosure is negotiated under Rule 144A instead. The EU Securitisation Regulation uses ESMA templates for underlying exposures, investor reports, and significant events, a framework now under revision, with ESMA consulting on a simplified template for private securitisations ahead of the wider Level 1 review. Basel III is a capital framework rather than a template-driven disclosure regime, though its Pillar 3 requirements do cover securitisation exposures, and reliable securitization data still matters for due diligence, risk management, and capital treatment.
Which requirements apply depends on the jurisdiction, asset class, offering type, and role a firm plays in the transaction. Across them, teams still need data that can be traced, validated, and transformed consistently.
Where structured finance data prep breaks down
A servicer changes a field. A new transaction uses a different naming convention. A trustee report calculates a metric differently from the servicing tape. Each variation creates another reconciliation task.
When those transformations depend on manual data preparation, spreadsheets, or isolated scripts, several problems repeat:
- Business logic becomes difficult to audit and reproduce.
- Schema changes require repeated manual intervention.
- Reconciliation logic becomes dependent on individual analysts.
- Data lineage becomes harder to trace.
- Downstream reports can drift from source data.
Close the structured finance data prep gap with Prophecy
Securitization analytics teams need a way to reshape origination tapes and the servicer tapes that later diverge from them, reconcile investor reports, and prepare analytical or regulatory datasets without leaving the governed cloud data platform.
Prophecy is an AI data prep and analysis platform that puts agentic data prep directly into the hands of business data teams.
AI agents can help harmonize schemas, draft transformations, and generate validation logic. A visual interface keeps those workflows inspectable, while code-backed execution lets analysts and engineers review and extend the logic. Workflows can run repeatedly on Databricks, Snowflake, and BigQuery so prepared data stays inside the governed cloud platform.
Consider a recurring servicer tape. A servicer adds fields, renames a column, or changes how delinquency status is represented. Instead of updating spreadsheets, scripts, joins, and validation rules separately, analysts can update and validate the transformation once as part of a repeatable structured finance data workflow.
The same approach can support standardizing tapes from multiple servicers, reconciling servicing data with investor reporting, preparing Schedule AL datasets, and creating surveillance-ready data.
The goal is not to replace specialized origination, servicing, structuring, disclosure, or surveillance software. It is to remove the iterative data prep and analysis cycles that stall the work between collaborators, for example between originator and structurer, structurer and portfolio manager, analyst and investment committee; where today every new question means another round of manual reshaping before anyone can answer it.
By moving transformation and reconciliation logic into governed cloud data workflows, analytics teams can preserve lineage, access controls, and repeatability while responding faster to changes in the data.
With Prophecy, securitization teams can build and adapt governed data workflows in-house.
Ready to explore the Prophecy platform?
Book a demo to see how agentic data prep can accelerate your structured finance operations.
