Publication register for fund documents
A permanent address for every fund document.
Each document keeps one canonical address. Each publication carries the period it was in force, and the version it replaced stays on the record. Ask the register what was published on any date and it answers from the record rather than from memory.
Address referenced by the document
https://documents.examplefunds.com/d/XF0000000018-kid-en
Resolves to the version that is current today, and to nothing else. Printed in the document, reported to the recipients that collect document links, held in your own records. The address carries no fund key and no ownership: a new share class, a change of manager or a rebranding leaves it exactly as it is. Every version below keeps its own dated address, which stays reachable after it stops being current.
- 2026-04-21CurrentValid from 21 April 2026, open/d/XF0000000018-kid-en/2026-04-21
- 2025-03-1212 March 2025 to 21 April 2026/d/XF0000000018-kid-en/2025-03-12
- 2024-02-2828 February 2024 to 12 March 2025/d/XF0000000018-kid-en/2024-02-28
- 2023-01-099 January 2023 to 28 February 2024/d/XF0000000018-kid-en/2023-01-09
The problem
A website publishes files. A register records publications.
A CMS is built to put a file where a browser can fetch it, and it does that well. What it holds afterwards is a file name, an upload timestamp and a folder. None of those establish which document this is, which version it replaced, or the period during which it was the one in force.
So the record ends up outside the system that published it: in a spreadsheet, in an email thread, in the memory of whoever produced the document. It is usually correct. It is just not written down anywhere that can be asked a question.
This is a data model, not a failing. Publishing a KID, a prospectus, a supplement, an annual or semi-annual report, a set of performance scenarios — each of those is an event with a date, a predecessor and a period. A file system has nowhere to put any of it.
It shows up in ordinary questions. Which KID was in force on 14 June 2025? What did this one replace, and when did the change take effect? Was the scenario file for March 2026 ever published, or only produced?
What the file system holds
- kid-nordic-equity-a-2025-03.pdf
- Uploaded 14 March 2025, 09:41, by the website account
- Folder /wp-content/uploads/2025/03/
- The file it replaced, if it was not overwritten
What the register records
- Document identity: the KID for XF0000000018, in English
- In force from 12 March 2025 until 21 April 2026
- Supersedes the version from 28 February 2024
- Canonical address /d/XF0000000018-kid-en, unchanged across all four versions
- SHA-256 recorded on arrival, and an event log entry that cannot be rewritten
Both columns describe the same PDF. The left one is what a website can tell you about it; the right one is what a register keeps. Nothing on the left is wrong — it is simply not a record, and it cannot be queried, exported or handed to anyone who asks.
What the register holds
Attached where it belongs, addressed on its own.
A document is attached to a share class, to a fund or to the publisher itself — and to more than one where that is the truth of it. The attachment decides where the document is shown and how it is grouped. It does not decide the address: every document has its own, unchanged by anything that happens to the structure around it.
Each language version is a document in its own right, with its own address and its own publication date. Periodic documents are separate too: the 2023 annual report is not an earlier version of the 2024 one, and both remain current for their year.
Fund. Documents that apply to the fund as a whole.
/d/example-nordic-equity-prospectus-en- Prospectus with fund rules
- Annual reportone per financial year
- Interim report
- Sustainability-related disclosures
- Trading calendarPDF · CSV · XLSX
Manager. Published in your own name. Practice differs between markets, so the list is yours to set.
/d/example-asset-management-remuneration-en- Remuneration policy
- Engagement policy and annual report
- Complaints handling
- Summary of investor rights
- Standardised data templatesEPT · EET · EMT
- /d/{slug}
The document, at the version current today
- /d/{slug}/{date}
One named version, reachable for good
- /p/{publisher}
The portal: notices first, then a table of your funds and the documents each one has
The paths are the same whether documents are served from our domain or from yours by CNAME. Slugs are proposed on upload from the identifier, the document type and the language, so the address reads as what it is. Rename a document and the previous slug keeps answering — permanently, and without a redirect, because a redirect is what makes a collector record the wrong address.
Standardised data templates
EPT, EET and EMT are held as documents among the others: a file with a type, a version, a date and a validity period. We store them unchanged and read nothing inside them. You keep a record of what was delivered and when, and an integration can fetch the latest template from a fixed address.
Notices to unit holders
A dated publication forming a feed at the level you choose. A statutory period runs from the date of the notice — on a material change, unit holders are commonly entitled to a redemption window counted from it. Amended fund rules take effect at the moment they may be applied, without anyone remembering to press a button that morning.
Evidence
What was published on 14 June 2025.
The register answers two questions, not one. Which document is current?— the canonical address, resolved now. Which document was current on a given date? — the same question asked of any day in the past.
Every version has a valid-from date. Valid-to stays open until the version is actually replaced or withdrawn. Nothing is deleted; it is superseded. Ask the register for a date and it returns the documents that were current on that date, with a manifest listing each file, its SHA-256 and its validity period, signed with our key so the recipient can verify the contents without trusting our website.
Behind it sits a hash-chained event log. Each upload, publication and supersession is written once, with the file hash, the time, the user and the hash of the preceding entry. History cannot be altered afterwards without the chain showing it.
A date in the future is never answered. Scheduled publications are visible to you and to no one else until the day they take effect.
Ask the register as at a date, and it returns the version that was current on it.
- Asked as at
- 2025-06-14
- Version returned
- 2025-03-12
- Validity period
- 12 March 2025 to 21 April 2026
- SHA-256
- 9f2c4e1b7a08d3c5b61ea479d0c8f215
- Permanent address
- /d/XF0000000018-kid-en/2025-03-12
Where we fit
After the document is approved. Before it is referenced.
Approved documentKilospringWebsite · EPT · Distributors
Your process is unchanged
The document is produced, checked and approved exactly as it is today, by the same people in the same tools. We have no view on any of it and no step in it. The register begins at the point where an approved file is ready to be published.
We publish and record
The file is stored byte for byte, given its canonical address, and recorded with the date it takes effect, the version it supersedes and the period it will be in force. Publication happens at the moment you choose, not at the moment you upload.
Everyone else refers to it
Your website links to the address. The EPT publication fields carry the address. A distributor or data vendor collects from the address. None of them are replaced, and none of them have to be told again when a new version is published.
You do not replace your website, your KID production, your administrator or your distribution arrangements. The register sits alongside them and holds the one thing none of them holds: the record of what was published, when, and in place of what.
Scope
What Kilospring does not do.
Written down because it is the part that decides how much of your organisation has to look at us before you can say yes.
We do not produce, calculate or translate a fund document
We do not review, check or approve what a document says
We do not decide whether an annual review is due, or when one is
We do not replace your website
We do not file or submit anything to a regulator, a distributor or a data vendor
We do not change a file you have uploaded, ever
The service is a technical publication service. It is not an outsourcing of anything you hold a licence for, and nothing in it requires you to delegate a regulatory judgement.
Distribution
Report the address once.
We are not a distribution network and we do not deliver anything on your behalf. What we provide is the one address your website, your EPT and your distribution counterparties can all point at — and that keeps pointing at the right file when the document changes.
Where a publishing chain to data vendors, platforms and distributors exists, it is address-based: you submit where the document lives, and they fetch from there. When the address is permanent, the submission is made once instead of corrected each time a file is replaced.
Documents are served from your own domain by CNAME, as standard rather than as an upgrade, so the referenced address sits on the manager's website.
Because every address and date is already recorded, delivery is a matter of selecting columns. Exports use saved presets and come as CSV, XLSX or JSON; a read API returns the published record for a fund or a share class, including what applied on a given date.
Templates generated from your own or your administrator's systems do not settle the publication fields: they are only right if the addresses and the KID date are recorded somewhere, and in practice that is done by hand. Hence the familiar defects — a KID date past the twelve-month point, the same URL in 02190 and02200 where two separate sets are expected, and links pointing at the wrong share class.
- 00070_PRIIPs_KID_Publication_Date
date of the latest KID
- 00075_PRIIPs_KID_Web_Address
direct link to the KID
- 02190_Past_Performance_Link
past performance
- 02200_Previous_Performance_Scenarios_Calculation_Link
previous scenarios
- 00120_Reference_Language
language of the linked pages
FixUrl
One row per document in the collection file, with ISINs comma-separated where share classes share a document, and a column recording whether the address is fixed.
Link_Type
The same question in the generic template: one row per ISIN, valued fixed or non-fixed.
The industry already has a name for it. The collection files you fill in for data vendors and platforms ask whether the address is fixed, which is the question the register answers by construction.
Security and data
Your documents, held plainly and kept within reach.
Files and metadata are held in storage restricted to EU jurisdiction, and we hold no personal data beyond your contact people. A file you upload is stored byte for byte and never altered, its hash recorded on arrival. Everything we hold for you — the documents, the version history and the event log — can be exported in full at any time, so leaving costs you a download rather than a negotiation.
The service is deliberately narrow, and that is what makes it easy to approve: it is a technical publication service, not an outsourcing of anything you hold a licence for. We do say mechanical things about our own storage — that the KID on file is dated 12 March 2025, or that no scenario file has been uploaded for March 2026 — as fact, never as advice.
We will appear in your register of information as an ICT third-party service provider, and the contractual terms under Article 30 of DORA apply to us however small the service is. The supplier dossier is written before the first conversation rather than after it: contractual annex, registration details, sub-processor list, place of operation within the EU, and an exit plan with a full export.
Receive the files you upload or forward by email
Give them permanent addresses
Keep every version, with timestamps and validity periods
Publish at the moment you choose
Show a portal per publisher, with its products and documents
Ownership of every file and of the record around it
A full export at any time: the holding, the event log and a static mirror
Your addresses, served from your own domain
Your slugs, reserved to you and never reissued to anyone else
Getting started
We set it up, and you check it.
Onboarding is something we do rather than something we hand you. For the first customers it is roughly an hour of our time and a short conversation of yours.
We import what you publish today
You point us at the documents already on your website. We load them with the dates they carry, so the register starts with a history rather than an empty first day.
Addresses are established on your domain
One CNAME, and the addresses sit under your own host name. Slugs are proposed from the identifier, the document type and the language, and you approve them before anything is public.
Existing references are updated once
The links on your website and the addresses in your EPT are changed to the canonical ones. This is the only time they change: that is the point of them.
From then on you publish to the same addresses
A new version goes to the address the old one had. The former version keeps its own dated address, and the record of the change is written as it happens.
A good first step is one fund, with the documents you already publish. It is small enough to set up in an afternoon and complete enough to judge: the addresses, the version history and the answer to a date, on your own domain, with your own files.
Try it with one of your funds
Start with one fund, and see the record.
Tell us how you publish today and we will write back with how the register would hold your documents. If it looks right, we set up one of your funds from the documents you already publish, and you look at the result before anything is referenced anywhere. Nothing to install, nothing to commit to.
You can also write to info@kilospring.com, or look through the demonstration portal first. The firm and the funds there are fictional, and each document says so in its own text.