An obligation is an editable draft until you publish it, and publishing freezes a numbered version that alone generates filing periods.
A reporting obligation records which rules governed a filing, so your organisation can show a regulator the configuration used long after the obligation 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 from two years ago wants to know which rule set governed it on the day you filed. If that answer lives in a duty's current settings, any edit made since changes it without anyone intending that.
Publishing freezes the draft under a version number, and no platform route updates or deletes a published version, 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.
A filing period reads the same indexed ledger records, held at the same block height and log position, that back the platform's transfers, holdings and prices. Its chain figures come from the platform's own indexed record of the chain, which an auditor can recompute from the chain's blocks, rather than from a separate reporting system's copy. Asset Lifecycle describes why fewer handoffs mean fewer reconciliations.
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 keeps a catalogue of obligations for common regimes, which only the platform can edit. Each organisation receives its own draft copy of every catalogue obligation, and reviews, edits and publishes that copy like any obligation it 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. An organisation owner or a platform administrator can create, edit, publish, or disable an obligation. A Reporting reader can read its configuration: an organisation owner, a platform administrator, or a member whose acting wallet holds the Permission manager, Auditor, Compliance manager or System manager role on the organisation's system.
An obligation can require maker-checker sign-off on its filings. This setting defaults to enabled. Maker-checker makes a second approver sign off each filing. Publishing needs no second approval: it only checks that two eligible approvers exist. 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. An obligation editor can also generate a filing for an ended date range. Its period is linked to the current published version but sits outside the cadence, so it never falls overdue and the schedule does not change.
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. The platform generates the filing's files. Your organisation uploads them to the authority, then records the submission and the authority's receipt reference, or a publication reference, and that record makes the period fulfilled. An unfiled period becomes overdue when its deadline passes.
A period waits for chain finality before it opens, and disabling the obligation waives only a period still waiting, not an open or overdue one.
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.
How a report format shapes the files the authority receives
A report format is the part of a reporting obligation that sets how the authority wants its files laid out. It names each file and its columns, and says where each column reads its value: a data point, a field of a generated report, or fixed text. Without a format, a filing contains the standard reports its obligation selects. An obligation can select the security incidents report, which lists security alerts and operations cases of kind security. An operations case is the platform's record of an incident that an operator acknowledges and resolves. The platform raises a security alert and a security case for a burst of failed sign-ins, a burst of refused authorisations, a privileged role grant and a new API key, and the report lists them. It lists nothing the platform does not detect, so an empty security incidents report does not show that no incident took place.
Each column can also write its value the way the authority's template expects. A number can be scaled from token base units by the token's decimals, rounded to fixed decimal places, and written with the authority's decimal and thousands separators. At 18 decimals and two places, 1500000000000000000 is written 1,50 in a template that uses a decimal comma. A date takes a layout such as DD/MM/YYYY and a time zone, so an event at 21:30 UTC on 30 September is dated 1 October in Dubai. Text can be upper or lower case, and an EVM address can use its checksum case.
A CSV file can set its delimiter, its byte order mark, and its line ending. A spreadsheet whose list separator is a semicolon then opens the file without an import step.
The format is versioned with the rest of the obligation. Publishing checks each column against what it can know before any data exists: the data point or EVM report field the column names, and whether its format suits the data point's type. A field the report does not have, a number format over a text data point, or a CSV setting on a spreadsheet file stops the publish with a message that names the column. A report field holds text, so generation checks each value as it writes the file. A value the format cannot write stops the filing at the first such row, and the message names the file, the column, and the row. A second authority layout for the same report needs only a second format, never a platform release.
Which reports a filing can carry
Each filing generates the reports in its obligation's report set. The platform's report families are grouped here by the question each answers. The names are the ones the Console shows under “Report” in the obligation editor.
The Console offers every family the deployment serves, and its obligation editor sets one report for each draft. The Platform API takes several reports on one draft. Send them as the report set of POST /api/ or PUT /api/. Four custody operations reports are served only while custody operations are switched on, which they are by default. They are the wallet register, incoming transfers, outgoing transfers and the withdrawal destination whitelist.
The trade journal holds one row for each executed venue trade and each bust. It is also the source of the per-trade reports the platform sends to a regulator over FIX, described in Trade reports. For a venue in the Abu Dhabi Global Market, FSRA venue reports lists the venue matched trades columns that carry the MIR 3.6.7 post-trade fields and the provisional FSMR s.149 order and transaction reports.
Service availability
This report measures how the custody and API services performed over the period. It needs a period with a start, so it cannot be generated for an open-ended window. Each row is one of five kinds, named in the rowKind column:
provider-availability: one row per custody provider configuration, with its availability percentage over the period and the milliseconds it spent in any health state other than healthy.health-window: one row for each window a custody provider spent outside the healthy state, with its start, end and health.api-route-group: one row per API endpoint tag, or per route template where an endpoint has no tag, with the request count, the count of responses with a status of 400 or higher, the average latency and the latency that 95 per cent of requests stayed under.delayed-operation: one row for each delayed custody operation, of two sorts.- A custody withdrawal created before the period end whose cancellation window closed before the period end. The expected time is that window's end.
- A deposit whose screening outage or screening freeze case passed its recorded expiry before it was resolved.
incident-window: each operations case that overlaps the period, clipped to the period, with its kind, subject and recorded detail.
Gas wallets
For each network in the filing's scope, this report lists the wallets that pay for the organisation's transactions: the paymaster deposit, the bundler and the gas station. Each row carries the network, role, address, balance and threshold in wei, the time of that balance, the last top-up and its amount, and the time the newest funding alert for that wallet was raised. The status column reads empty at a zero balance, low below the threshold and funded otherwise. The bundler's threshold is its top-up level, sized from the network's live fee quote when the snapshot was taken. A snapshot recorded before that level was stored carries no bundler threshold. Balances come from the latest recorded balance snapshot at or before the filing's as-of time. A network where the organisation's system has no account abstraction ready produces no rows.
Corporate action entitlements
One row covers each holder allocation of each previewed corporate action whose record date falls in the period. An action whose preview recorded no record date counts in the period it was created in. Each row carries the action, token, event type and status, the record, ex and payment dates, the holder's participant and wallet, the eligible quantity, the payout asset and its decimals, and the gross entitlement the preview allocated.
The platform computes no tax withholding. Every row reports a tax rate and tax withheld of zero, a net entitlement equal to the gross, and the tax status “not computed”, so an issuer that withholds off the platform states the net amounts in its own records.
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. It has no status field, and counts as published once it has a published version. 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 organisation owners before it commits. DELETE /api/ disables an obligation and removes nothing, and no call re-enables a disabled obligation: disabling waives eligible periods while preserving their records, and a duty you want back needs a fresh obligation. An organisation owner or a platform administrator can make changes, and a Reporting reader 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. GET /api/ lists every published version of the obligation with its number, publication time, publisher and frozen configuration, so an integration can read a past version at any time. 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.
An obligation can carry validation rules. Each rule is one comparison, using =, !=, <, <=, > or >=, over the obligation's data points, the named values a filing reports. For example, {class- checks that the units of two share classes add up to the total. Each rule has a severity of blocking, warning, or informational and an effective date range. Publishing refuses a rule that does not parse, is longer than 2,000 characters, names an undeclared data point, or compares values of different types. Write a date as "2026-09-30" or as a date and time with an offset, such as "2026-09-30T00:00:00Z". A date and time without an offset does not compare with a date. When a filing is generated, the platform checks each rule in force on the period's last day. A failed blocking or warning rule stays on the filing as a finding that names the rule, the data points, and their values. Approval is refused while a blocking finding stands. Correct the data and generate the filing again. Generating a filing again, like replacing it, opens a fresh attempt that the platform checks against the rules again, and resolves the findings of the attempt it replaces. Approval is also refused while a warning finding is open. An organisation owner other than the person who prepared the filing accepts open warnings with the AcceptRuleWarnings act, a written rationale, and the filing's row version. A failed informational rule never blocks approval.
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 owners. 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.
How an anchor proves a filing was not altered
A version records which rules governed a filing. An anchor lets a regulator or auditor confirm that a copy they hold is byte for byte the filing the organisation fulfilled. Anchoring covers filings. FIX trade reports sent to a regulator are not anchored, as Trade reports explains. Anchoring is off until an organisation owner or a platform administrator turns it on for an obligation in Obligations.
What is hashed
A filing is stored as an ordered list of files, called parts. The platform takes the SHA-256 of each part's bytes and its length in bytes, builds a short text manifest from them, and takes the SHA-256 of that text. The result is the manifest digest.
A reviewer can rebuild the manifest outside the platform:
- Write the first line as
dalp..reporting. artifact- manifest. v1 - For each part, in order and numbered from 0, write one line with the part number, the part's SHA-256 as 64 lowercase hex characters without a
0xprefix, and its length in bytes as a decimal number. Separate the three fields with the unit separator character, U+001F. - Join the lines with a line feed, U+000A, and add no line feed after the last one.
- Take the SHA-256 of the UTF-8 bytes of that text. It is the value the approver checks in the “Approve” dialog and the value the registry stores. Changing one byte of any part, adding or removing a part, or putting the parts in a different order produces a different manifest digest.
Where it is written
When a filing of an anchored obligation is acknowledged or published, the platform writes the filing's manifest digest into the document anchor registry: an add-on contract on the organisation's own system, on the network chosen when anchoring was turned on. Each entry records the issuer identity, the subject identity, the digest, the document type, the label and the block it was written in.
The current registry implementation has no update and no delete function. The registry runs behind a proxy, and a new implementation decides what the registry reads back. A System manager on the organisation's system can point the registry's add-on type at a new implementation through the system's add-on registry, and that change is itself an on-chain transaction anyone can read. The registry refuses every write once its add-on registration is archived. Otherwise it accepts a write only from a sender with an active identity that holds a claim key on the issuer identity, and only when the trusted issuer registry trusts that issuer for the anchoring topic on the subject. The platform writes each filing at most once, and a repeat of a write that already landed returns the existing entry instead of adding a second one.
How a copy is checked
A holder of a copy checks it with “Check a document”, which appears on the Anchor registry screen and beside an asset's documents in the Console and the Investor portal. The holder names the issuer identity and chooses the files in the order they were delivered. The browser hashes each file and sends only the digests and lengths, so the document never leaves the holder's machine. The platform recomputes the manifest digest, finds the registry that the named issuer's own system runs, and looks for that issuer's entries under the digest up to the last block the indexer has read. The same check is POST /api/, which needs a signed-in caller and no organisation or Reporting role, as the Platform API reference describes.
The issuer is required because two organisations can anchor byte-identical files, and an entry that only names an issuer proves nothing when it sits in a registry the issuer does not run. A reviewer who does not use the platform can read the same entries from the registry contract's public read functions, by digest or by subject identity.
What each answer means
A not-found answer means that no matching entry was read up to the named block. An altered copy produces this answer because its manifest digest differs from the anchored one.
An anchor proves that a copy matches the bytes the platform held for the filing when it wrote the anchor. It does not prove that the authority received those bytes, because the platform does not deliver a filing and a user records its submission and the authority's receipt. It does not prove that the filing was correct, and it never changes whether the duty was met: a failed anchor leaves the filing fulfilled with a finding, as Filings describes.
Frequently asked questions
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. The filer's calendar and the authority's calendar can disagree on which days count, so two organisations on the same cadence can land on different deadlines in different jurisdictions. The version's deadline rule names which calendar applies to which half of the calculation.
Can the platform deliver every authority file as one upload?
No. Each authority file is a separate file in the filing, and the report format has no option that joins them. Authority portals usually take one template per filing type or module. The FSRA electronic prudential reporting system, for example, takes one Excel, CSV, or XBRL template per module, so a bundle would need to be split again before upload. Upload each file to the template slot the portal names.