Euronext turns a Final Terms PDF into data in about 52 seconds

Twenty-five fields from a Final Terms PDF in under a minute, checked before they move on

Industry
Financial Services
Solution
Automation

Twenty-five fields from a Final Terms PDF in under a minute, checked before they move on

Industry
Financial Services
Solution
Automation

Euronext turns a Final Terms PDFinto data in about 52 seconds

Client
Euronext
Industry
Financial Services
Solution
Automation
Technology
Gen AI
Team
4 DareData engineers
~52 secondsper document in production, against 15–20 minutes by hand
~95%extraction accuracy on the Dublin exchange
~108 hoursof compute a year, replacing 1,875–2,500 analyst hours

Dublin figures, measured in production. Milan runs in shadow mode, with accuracy still being measured

Compliance analysts at Euronext read fifteen to thirty pages of Final Terms for every listing, find the dates, identifiers and amounts, and type them into the next system, about 7,500 times a year. A retrieval pipeline now indexes each document, searches it once per field and validates every value before it is passed on. On the Dublin exchange it runs in production at about 52 seconds per document and about 95% accuracy. The Milan exchange runs a harder version of the same engine in shadow mode.

With DareData, Euronext:

  • Extracts about twenty-five fields per document in about 52 seconds, against 15–20 minutes by hand
  • Reaches about 95% accuracy in production on the Dublin exchange
  • Replaces 1,875–2,500 analyst hours a year with about 108 hours of compute
  • Handles the same field named differently by different issuers
  • Adds new fields, prompts and validation rules in YAML, with no code change
  • Extends to about 55 bilingual, product-aware fields on the Milan exchange, in shadow mode

The challenge

Thousands of long documents read by hand

Every listing on the exchange comes with a Final Terms document of fifteen to thirty pages. Compliance analysts read each one, locate the dates, identifiers, amounts and regulatory flags, and enter them into downstream systems. A misread maturity date or a wrong identifier has consequences for the listing approval, so the work has to be both fast and exact.

Slow and easy to get wrong

Each document took fifteen to twenty minutes by hand, across about 7,500 documents a year. The work is repetitive, and repetitive work is where small reading errors creep in.

The same field, three different names

Issuers do not agree on wording. "Maturity Date" appears as "Redemption Date" or "Date of Maturity" depending on who wrote the document, so matching against a fixed template does not hold up.

Too long to read whole

The documents are often too long to hand to a model in one piece, and the irrelevant pages cost tokens while making the answers worse. Retrieval has to happen field by field, not document by document.

The solution

Retrieve only what each field needs

The system is a retrieval pipeline built for long financial documents. Instead of feeding a whole Final Terms PDF to a model, it first indexes the document into searchable segments, then retrieves only the parts each field actually needs and extracts the value from those.

Chunking is token-aware and treats tables as atomic units, kept whole with their headers, with overlap between chunks so that context survives at the boundaries. Retrieval runs once per field, using a multi-keyword vector search that covers the different names issuers give to the same thing. When a field is not found on the first pass, the system searches again with different segments before giving up.

Every field is defined in YAML: what to look for, which prompt to use, when to skip it and how to validate it. Dependent fields are only extracted when they apply, so a public offer start date is only looked for when there is a public offer. Adding a field or changing a prompt is a configuration change, with no code deployment.

Extracted values go through strict validation before they are passed on: date formats, allowed values and business-day checks. An invalid extraction is flagged for an analyst, never silently accepted. Results and an audit trail are stored for every document, because in a listing process each value has to be traceable.

The infrastructure is serverless and event-driven, built on Azure OpenAI and Azure AI Search for retrieval and extraction, with AWS Lambda and Step Functions running the workflow. Documents are submitted asynchronously and results are delivered by webhook. The same infrastructure serves both exchanges, each with its own configuration: Dublin in production, Milan in shadow mode with product classification, bilingual search and coupon validation added on top.

How it works

From data to decisions, in 4 steps.

  1. 01Chunk with tables intactToken-aware chunking keeps each table whole with its headers, with overlap so context survives the boundaries.
  2. 02Search per fieldA multi-keyword vector search runs for every field, so a date is found whatever the issuer called it.
  3. 03Rules in configurationField definitions, prompts, skip conditions and validation rules all live in YAML, so adding a field needs no deployment.
  4. 04Extend, don't rebuildThe second exchange added product classification, bilingual search and a coupon validation module on the same infrastructure.

The impact

Seconds per document, hours per year

  • ~52 secondsper document in production, against 15–20 minutes by hand
  • ~95%extraction accuracy on the Dublin exchange
  • ~108 hoursof compute a year, replacing 1,875–2,500 analyst hours

On the Dublin exchange the pipeline is in production. A Final Terms PDF becomes about twenty-five validated fields in about 52 seconds, at about 95% accuracy. At about 7,500 documents a year, that is roughly 108 hours of compute in place of 1,875–2,500 hours of analyst time. Analysts review what the system flags instead of retyping every document.

The second exchange, Milan, is the harder extension. It needs about 55 fields per document, content in two languages, extraction logic that depends on the product type, and financial rules to check the values against. It runs on the same infrastructure in shadow mode: in parallel with the existing human process, not yet replacing it, and without a published accuracy figure so far.

Because fields, prompts and validation rules live in configuration, adding a field is a configuration change rather than a release. The tool can follow the business as document formats and requirements change.

The team

The people who built it.

  • José CoutinhoSenior Data Scientist & Project Manager
  • Adriano CampinhoSenior Data Scientist
  • Luís NoronhaSenior Data Scientist & Project Manager
  • Miguel FernandesData Scientist

Your AI story, next.

Tell us what you want AI to do for your business. We design, build and run it with your teams, and measure it like the stories above.

  • 01Use cases chosen for value, not hype
  • 02Systems built into your stack and data
  • 03Run, monitored and improved after go-live