A practical route from permitted ESMA disclosures to a participant controlled data service for AI workflows

Let's start with the business: a credit committee question

Consider a representative business scenario. An investment manager holds positions across several European residential mortgage-backed securities. Before the weekly credit committee, the portfolio manager asks a direct question: are arrears increasing, and are they concentrated in particular origination vintages or regions?

The disclosures exist in ESMA-registered securitisation repositories, but the question crosses transactions, reporting dates and formal template fields. The analyst would otherwise have to find the right downloads, confirm field definitions and repeatedly align data cut-off dates. Instead, the manager has created a controlled internal analytical mirror of the disclosures it is permitted to retain and process. Deeploans has ingested, validated and standardised those files, while preserving their source and reporting dates. The AI client uses the MCP server to inspect the RMBS tables, construct valid filters and preview a small result. The analyst checks the lineage and runs the full query through the governed API. The official source remains authoritative, but the participant now controls how its analytical copy is validated, queried and reused.

The market participant controls an analytical mirror, not a regulated repository. Upstream disclosures are obtained from repositories registered and supervised by ESMA, under the applicable access terms. Deeploans creates a controlled internal copy and exposes it through the Deeploans API. MCP is the interface between that governed data service and an AI client. The copy does not acquire the status of an ESMA-registered securitisation repository and does not replace the source.

Figure 1. A market participant can turn permitted repository disclosures into a controlled internal analytical mirror without changing the status of the official source.

The data starts with the securitisation transparency regime

For in-scope public securitisations, Article 7 of the EU Securitisation Regulation requires designated reporting entities to make prescribed transaction information available through a securitisation repository. ESMA explains the transparency requirements, while its disclosure instructions define standard templates for underlying exposures, investor reports, inside information and significant events. The underlying exposure templates cover asset classes such as residential real estate, commercial real estate, automobile and consumer lending.

ESMA maintains the register of supervised securitisation repositories. The repositories collect, verify and distribute standardised disclosures. Article 17 provides access to investors and potential investors, among other specified parties, for their responsibilities and due diligence. Access, retention and processing still depend on the user's status, repository terms, applicable law, confidentiality and data-protection obligations. Standardised reporting templates therefore do not automatically make multi-deal, multi-period analysis convenient.

Building a participant controlled analytical mirror

For each market participant with the appropriate access rights and lawful basis, Deeploans can support an internal copy that is repository-equivalent in coverage and queryability for the disclosures the participant is permitted to hold. Equivalent describes the analytical copy, not its regulatory status. Because the participant controls ingestion cadence, validations, history, derived calculations, indexing, permissions and tool design, the mirror can be more controllable and useful for its own workflows than relying only on native query and download interfaces.

A shared analytical mirror also avoids rebuilding a separate integration for every agent. Teams can use different MCP-compatible models and agentic harnesses against the same schemas, calculations, permissions and audit trail. The client receives only the tools and data access that the participant configures.

Figure 2. One participant controlled data product can serve several approved agent workflows through the same governed MCP tool layer.

What the server exposes

The current open-source server provides seven tools. Together they support a discovery-first workflow.

A typical analyst session

A useful interaction begins with metadata rather than data. An analyst can ask an MCP-enabled client to work through prompts like these.

1. "Show me the Deeploans platform components and supported asset classes."

2. "List the API tables for the rmb credit type."

3. "Describe <table_name> and identify the fields that can be filtered."

4. "Build valid filter examples for that table."

5. "Return five sample rows from the filtered endpoint."

The first four steps can still provide useful structure when the data API is unavailable: OpenAPI discovery can fall back to the repository's local specification, and table descriptions and filter examples use local schema metadata. Live previews require the backend. The server defaults to http://localhost:8000, limits a sample request to at most 100 rows, and can send an API key in the x-algoritmica-api-key header.

Figure 3. Install Deeploans MCP, prepare its backend, register the local server with Claude Code and verify the connection.

Running the MCP server locally

The open-source server is installed from the mcp-server directory in the Deeploans repository and runs over standard input and output.

cd mcp-server

python -m venv .venv

source .venv/bin/activate

pip install -e .

deeploans-mcp

Claude Code can register the same local stdio process with one command, following Anthropic's MCP setup pattern. The double dash separates Claude's options from the server executable.

claude mcp add --transport stdio deeploans -- deeploans-mcp

claude mcp list

/mcp

A minimal MCP client configuration is equally small.

{

"mcpServers": {

"deeploans": {

"command": "deeploans-mcp"

}

}

}

The API backend is a separate service. It must be running for sample_rows to return live data. Keeping the MCP server separate allows its tools and descriptions to evolve without coupling them to the backend release cycle.

Why schema discovery matters

Loan-level disclosure data contains coded fields, reporting dates, asset-class-specific columns and formal no data values. A plausible field name invented by a language model is still the wrong field. The same is true of a filter that looks like ordinary query syntax but is not accepted by the API.

The Deeploans MCP design reduces that risk by making the model inspect the interface it is about to use. describe_table identifies column types and filterability. build_filter_examples turns that metadata into valid patterns, including equality, comparison, LIKE and negation conventions. sample_rows then lets the analyst verify the result on a bounded response before scaling the query. Clear, non-overlapping tool descriptions and compact results help the client select the right action without loading irrelevant structure.

Trust and access boundaries

MCP improves usability, but it does not remove the controls that make a regulated data workflow trustworthy. A production implementation should preserve five boundaries.

• Source authority. The participant's analytical mirror does not replace the official disclosure source or change the regulatory status of either party.
• Access and retention. Acquire, retain and process disclosures only when permitted. MCP should never be treated as a way around access terms, confidentiality, data protection or eligibility requirements.
• Data lineage. Retain the repository source, transaction identifier, reporting date, ingestion run and transformation version alongside the analytical tables.
• Schema versioning. Pin the ESMA template and Deeploans schema versions used for a result. A field definition or validation rule can change over time.
• Analytical verification. Treat samples as previews. Reproduce material figures in a controlled query or model pipeline before they enter an investment, risk or regulatory decision.

In a nutshell: a controlled analytical copy for each participant

Every market participant with the necessary access rights and lawful basis can use Deeploans to build a repository-equivalent analytical copy of the ESMA disclosure data it is permitted to hold. It can make that copy more controllable and useful for its own work by choosing validation rules, history, calculations, access policy and MCP tools. The official repository remains the authoritative source; the internal mirror turns permitted disclosures into a data product that the participant can govern and use across applications and agents.