Two terms cause more confusion in this programme than everything else combined: online and offline. They are read as "connected" and "disconnected", which is close enough to be wrong. Both are certified. Both synchronise. Both require an identifier per transaction. What separates them is when the identifier was obtained - and understanding that is what makes the move to equipment legible instead of arbitrary.
It is easy to read the S-MDF as "the thing that signs". In a real deployment it is the layer that integrates: it sits between the till software and the authority, receives the transaction, resolves its identity, calculates its place in the sequence, produces the signature, and keeps what has not yet been accounted for.
The schema of the sale as the till software declares it: lines, totals, transaction type. The module integrates that structure; it does not author it.
Every ticket is anchored to a unique identifier. One per transaction, never reused, and its origin is the platform rather than the module.
The module computes the sequence. It is not handed a position; it holds the counters, advances them, and stores their value at each cloture. Counters never return to zero.
Rows shaded green are the same in both modes. That is most of the table, which is exactly why the two terms get muddled - and why treating offline as a degraded or unsupervised mode is a misreading.
| Mode ONLINE | Mode OFFLINE | |
|---|---|---|
| Certified | Yes - the module is certified | Yes - the same module, the same certificate |
| Synchronises | With the data integration module | With the data integration module, locally |
| Identifier required | One per transaction | One per transaction |
| Sequence | Calculated by the S-MDF itself | Calculated by the S-MDF itself |
| Signature key | The taxpayer's | The taxpayer's |
| Identifier obtained | At the moment of sale, from the platform | In advance, from the last batch retrieved |
| Ticket delivered | Immediately to the platform | Cached locally, transmitted at the next connection |
| Depends on the network | At every single payment | Only at batch renewal |
| QR first line | ONLINE | OFFLINE |
| Bound by | Nothing - it is live | Available tickets remaining, and time since sync |
In software mode the authority closed the network gap with a small cache held per module. That cache is what makes the S-MDF pivotal rather than incidental: while disconnected, it is simultaneously the issuer of record, the ledger and the state machine.
Software mode assumes the network is usually there and occasionally absent. Two realities break that assumption, and neither is exotic.
Rural taxpayers, valleys, interior regions, markets. Not an outage to be ridden out - the normal condition. A scheme that treats permanent disconnection as an exception has excluded a part of the economy by design.
Some taxpayers should not carry a live path between their point of sale and anything outside. Connectivity is an attack surface; removing it is a legitimate security posture, not obstruction. Offloading the network is a requirement, not a preference.
And here is the thing worth carrying across, because it is the same mechanism arriving from the other direction: in the El-Fatoora flow the authority obliges a key that encapsulates the certification of user identity together with its metadata, so the taxpayer legally signs their own invoices and receipts.
A taxpayer signing an electronic invoice does not hold an anonymous key pair. They hold a certificate issued by the national certification authority, TunTrust, which binds their legal identity to the key and carries the metadata that says who they are. Signing an invoice with it is not a technical gesture, it is a legal act attributable to a named person or company.
That is exactly the cryptographic part the equipment carries internally. El-Fatoora proves the mechanism works at national scale on the B2B side, with the key held by the taxpayer. The TOE takes the same idea and seals it inside the component, so the till case gets a legally attributable signature without depending on a live path to anything at the moment of signing. Same trust anchor, different custody.
To reach the E-MDF you have to be trusted, and trust here is not a role or a password. It is a fiscal kernel layer standing between the caller and the equipment, authorised by a trusted certificate, and that authorisation is what guarantees the retrieval from the TOE is correct: the right identifiers, the right sequence, out of the right component, unaltered on the way.
Without that layer there is no safe read at all. The equipment holds the cache, the storage and the sealed key, and something has to reach them for an audit, for a control, for the taxpayer's own accounting. The three rules below are the whole security argument, and the console beneath them enforces each one.
Not a copy of its data, not a mirror, not a cached credential. The component must be physically there and answering. Absent equipment means no access, which is a refusal rather than a fallback.
The same sealed identity that signs is what unlocks the read, and the kernel layer presents a trusted certificate to be admitted at all. Nothing outside the component can authorise a read of what is inside it - which is what makes the boundary real rather than drawn, and what makes the retrieved identifiers trustworthy rather than merely returned.
The taxpayer reads their own journal, their own counters, their own tickets. The console is not a privileged back door; it is the ordinary front door, and it happens to be the only one.
Below: the general architecture. A console session against the equipment, written as it behaves rather than as any one product implements it.
Illustrative architecture only. It describes the access model implied by sealed cryptographic storage - presence, identity-based unlock, own-data scope, nothing retained by the host - rather than the interface of any product. No implementation was examined to produce it.
No line to the outside, and still a legally signed receipt, a continuous sequence and an archive the authority can collect. Participation stops depending on infrastructure that is not coming.
Removing connectivity from the point of sale becomes compatible with compliance instead of opposed to it. The security-conscious merchant is no longer the awkward case.
Identifiers issued against identifiers returned, sequences continuous or not, packages arriving or missing. The centre stops trying to be present at every sale and starts looking at what came back.