Reporting Obligation
A reporting obligation lets your organisation prove to a regulator which rules governed a filing, and keeps that proof fixed even after the duty changes.
An obligation is an editable draft until you publish it; publishing freezes a numbered version. Only a published version generates filing periods, so a period stays explained by the version it came from, not by whatever the obligation says today.
A reporting obligation lets your organisation prove to a regulator which rules governed a filing, long after the obligation itself has moved on. You configure the duty as an always-editable draft of what to report and by when.
Publishing freezes that draft into a numbered version; editing the obligation afterward never touches a version already published.
The platform generates filing periods from a published version's cadence. Each period stays linked to the version that defined it.
Why a filing needs a rule set that cannot move
A regulator asking about a filing you made two years ago is not asking what your reporting configuration looks like today. The regulator is asking what rule set governed the filing on the day you made it. If that answer lives in a duty's current settings, an edit made any time between the filing and the question changes the answer without anyone intending it to.
A reporting obligation exists to close that gap. Publishing freezes the draft under a version number that nothing afterward can rewrite, so a filing from three versions ago still points at the exact deadline rule, scope, and data points that produced it. What a version proves states the limits of that guarantee.
Regulatory reporting usually adds one more system to that chain. Asset Lifecycle names the pattern for the platform as a whole: a typical programme runs issuance in one system, identity screening in a second, custody in a third, trading in a fourth, and settlement and reporting in a fifth. Each handoff between them is a reconciliation, a point where two systems' separate records of the same fact can drift apart. On this platform, the report generation step reads the same indexed ledger records, held at the same block height and log position, that already back this platform's transfers, holdings, and prices. A filing period comes from the identical ledger state an auditor could independently recompute rather than a second system's own copy of it.
Why an obligation and its version are different things
Configure each reporting duty as a separate obligation with a name, cadence, and required fields. Publish a new version when the duty changes. That version determines the requirements for later filing periods.
An organisation can have several obligations, such as transaction reporting and holdings disclosure, each with its own cadence and fields. The obligation holds an editable draft; editing alone creates no filing periods. The platform also provides catalog obligations for common regimes. Every organisation can read those obligations, but only the platform can edit, publish, or disable them. You can change obligations that your organisation owns.
Publish after you have checked the duty, cadence, and deadlines. Publishing freezes the draft into a numbered version and allows the platform to generate filing periods. A mistake remains in force until you publish a corrected version. Only an organisation owner or a platform administrator can create, edit, publish, or disable an obligation. Other members can read its configuration.
Each filing period retains the rule set that generated it. A reviewer can therefore trace a filing to a specific version even after the obligation changes.
An obligation can require maker-checker sign-off on its filings. This setting defaults to enabled. Publishing checks that two eligible approvers exist; it does not require both to approve the configuration. Choose the setting according to the review required for that reporting duty. A change takes effect in the next published version and does not alter earlier periods.
How periods appear on the calendar
A filing period is one dated instance of a duty, such as Q1 2026 transaction reporting with its remittance deadline. The platform creates periods automatically. Once an hour, it checks published obligations for calendar intervals that have closed since the previous check and generates each period from the published version's cadence. If the obligation was disabled first, the platform waives the period instead.
A new period waits until the platform's chain data reaches the finality required for reporting, then opens. This wait reduces the risk of filing figures that a chain reorganisation could change. Disabling an obligation waives periods still waiting for finality. Open and overdue periods continue unchanged. The API cannot re-enable a disabled obligation. A filed period becomes fulfilled; an unfiled period becomes overdue when its deadline passes.
A period waits for the underlying chain to reach finality before it opens for filing. Disabling the obligation only reaches a period still in that waiting stage, marking it waived; a period already open or already overdue keeps running untouched.
The Console's Obligations page shows each duty next to its current published version, and the Filing calendar shows the periods those versions generated, each row carrying a remittance deadline, an urgency badge, and coverage for each reporting family.
The data model behind the three terms
Three linked records represent the obligation, version, and filing period. The obligation holds the organisation's editable draft. Its published version determines whether the draft has been published; there is no separate status field. A version stores the configuration at publication and remains immutable. A filing period points to that version and records its reference interval and calculated deadline.
Editing the draft leaves published versions unchanged. A period generated under version 2 keeps that link after version 5 is published. Publishing allocates the next version number, stores the configuration, and sets that version as current in one atomic step. Earlier versions and periods remain intact. The API cannot restore an older version as current; publish a new version to change the configuration.
The integration contract
The API lets you list, read, create, and update obligations, publish a version, or disable an obligation. Publishing validates the draft, checks that its calendars belong to your organisation or the platform, and, when maker-checker is enabled, requires at least two members with an approver role before it commits. The API has no delete operation and no call that re-enables a disabled obligation: disabling waives eligible periods while preserving their records, and a duty you want back needs a fresh obligation. Only an organisation owner or a platform administrator can make changes; every member can list and read. Field-level constraints, request and response shapes, and per-endpoint error handling are in the API reference.
The obligation response identifies the current version number. The publish response returns the frozen configuration of the version it creates, so keep that response if your integration needs the configuration later; the API has no call that reads a published version afterward. The version's deadline rule specifies the business calendars used to calculate the due date. Use the filing-periods list to read the resulting periods and deadlines. It returns your organisation's periods ordered by remittance deadline unless you request another order. For each reporting family, it reports coverage as pending, covered, refused, or historically unconfirmed. Read these results instead of calculating periods and deadlines in your integration.
What a version proves
A published version records the dated configuration that governed a filing period. Later publications can supersede it, but the platform does not update or delete the earlier version.
Maker-checker at publication checks approver availability. When the setting is enabled, the organisation must have at least two people with an approver role. One owner can still publish alone. The check does not prove that a second person reviewed the configuration. If an eligible person later leaves, the organisation may need another approver before the next sign-off.
A version proves which rule set governed a filing. It does not prove that the filing was correct or complete. The filing period carries the submission's separate review trail.
Frequently asked questions
Do version numbers restart for each new reporting obligation, or share one counter?
Each obligation keeps its own count. Publishing your transaction-reporting obligation for the third time makes that publish its version 3, regardless of how many versions any other obligation your organisation holds has reached. Citing "version 3" to a regulator identifies a rule set only together with the obligation it belongs to, never by the number alone.
Could the hourly check ever generate two filing periods for the same interval?
No. The version and calendar interval uniquely identify each period. A second attempt to create the same period leaves the first record unchanged. More frequent checks or a restart therefore do not create another period for that version and interval.
Which calendar decides a period's deadline: my organisation's or the regulator's?
Both, and that is exactly where a cross-border obligation gets surprising. The filer's calendar and the authority's calendar can disagree on which days count, so two organisations on the identical cadence can land on different deadlines once they sit in different jurisdictions. Whose calendar wins for which half of the calculation is what the version's deadline rule names.
Reconciliation
Reconciliation lets your register stay the book of record while you prove it agrees with the platform's ledger, and know exactly when a gap needs a person.
Platform Event
A Platform Event tells an integration what happened, under a name and shape that cannot change, so it never has to poll the chain or re-derive finality itself.