The Glos­sa­ry of KassenSichV

There are a lot of com­plex tech­ni­cal terms around the cash regis­ter secu­ri­ty regu­la­ti­on — Kas­sen­SichV. In our glos­sa­ry, we exp­lain the mea­ning of TSS, Fiscal Sto­rage & Co.


The abbre­via­ti­on DSFinV‑K means “digi­tal inter­face of the cash manage­ment for finan­cial sys­tems”. Simply put, this is a uni­ver­sal data stan­dard for POS systems.

The DSFinV‑K will, based on the DFKA taxo­no­my of cash regis­ter data, con­tain a con­cre­te set of tables and fields, which are to be made avail­ab­le for tax audit pur­po­ses. This estab­lis­hes a stan­dard for finan­cial audits.

By means of this uni­ver­sal data stan­dard, manu­fac­tu­rers of POS sys­tems are now final­ly given assi­s­tance regar­ding the GoBD and Kas­sen­SichV requirements.


Fis­ca­liz­a­ti­on of cash regis­tersis the tamper-proof, elec­tro­nic record­ing and archi­ving of busi­ness tran­sac­tions. The aim of the Federal Minis­try of Finan­ce is to pro­tect the basic records of com­pa­nies against mani­pu­la­ti­on, and thus to avoid tax evasion.

In many coun­tries in Europe, the fis­ca­liz­a­ti­on of cash regis­ters is alrea­dy requi­red. In Ger­ma­ny, the Kas­sen­SichV must be imple­men­ted by 31.12.2019at the latest. 

From 1.1.2020, all record­ing sys­tems must comply with the requi­re­ments of KassenSichV.

Fiscal sto­rage

Legis­la­tors pre­scri­be the form of the data that has to be stored. The hard­ware ensu­res that these spe­ci­fi­ca­ti­ons are met and the data is stored accord­in­gly. Fiscal sto­ragefocu­ses only on sto­ring the data. How the data is achie­ved is not con­si­de­red here.

In con­trast, the Kas­sen­SichV and INSIKA are a pro­ce­du­re that dic­ta­tes how the data is to be pro­ces­sed (and also stored). The focus here is on how the data is created.

Elec­tro­nic record­ing system

An elec­tro­nic record­ing system is any device or soft­ware that elec­tro­ni­cal­ly records data about a busi­ness case. For examp­le, a cash regis­ter, an accoun­ting soft­ware, an ERP system, and so on. Cur­r­ent­ly, only those record­ing sys­tems that can record cash tran­sac­tions are rele­vant for the Kas­sen­SichV. The­re­fo­re, always when the busi­ness case can be com­ple­ted with a cash pay­ment (cash, debit card, vou­chers, etc), all ope­ra­ti­ons must be recor­ded in com­pli­an­ce with Kas­sen­SichV requirements.

For each busi­ness case, the elec­tro­nic record­ing system must start a log­ging which records the fol­lowing data:

  • star­ting time of the process
  • a unique and sequen­ti­al tran­sac­tion number
  • Ope­ra­ti­on type
  • Data of the operation
  • pay­ment method
  • time of com­ple­ti­on or cancellation
  • a test value
  • The serial number of the elec­tro­nic record­ing system or the serial number of the secu­ri­ty module.

GoBD & KassenSichV

Until now, the immu­ta­bi­li­ty of tran­sac­tions has been regu­la­ted in the GoBD (Princi­ples for the proper manage­ment and reten­ti­on of books, records and docu­ments in elec­tro­nic form and for data access). 

Howe­ver, this is neit­her law, nor regu­la­ti­on, but merely an admi­nis­tra­ti­ve requi­re­ment of the Federal Minis­try of Finan­ce. The Kas­sen­SichV now legal­ly regu­la­tes pro­tec­tion against data manipulation.


The so-called INSIKA pro­ce­du­re pro­mi­ses to offer a modern alter­na­ti­ve to the clas­si­cal fiscal sto­rage by means of cryp­to­gra­phic pro­ce­du­res. But the INSIKA method is hard­ware-based and requi­res so-called smart cardswhich must be con­nec­ted by means of card rea­ders or inte­gra­ted direct­ly into the cash register. 

The cash regis­ter sys­tems based on the INSIKA method deal with fre­quent errors such as unplug­ged card rea­ders or broken smart cards. The­re­fo­re, the relia­bi­li­ty of INSIKA-based record­ing sys­tems also depends hea­vi­ly on the hand­ling of the hard­ware com­pon­ents. In addi­ti­on, the com­pa­ti­bi­li­ty of the INSIKA method with mobile POS sys­tems that work via smart­pho­ne or tablet (iPad) is limi­ted. Moreo­ver, a smart card can easily get lost.

Kas­sen­si­che­rungs­ver­ord­nung — KassenSichV

The Kas­sen­si­che­rungs­ver­ord­nung (Kas­sen­SichV) regu­la­tes the tech­ni­cal requi­re­ments for elec­tro­nic record­ing and secu­ri­ty sys­tems, for examp­le com­pu­te­ri­zed cash regis­ter sys­tems and cash regis­ters. Also affec­ted by Kas­sen­SichV are: ERP sys­tems, indus­try soft­ware, accoun­ting sys­tems, etc.

The cru­cial factor is the cha­rac­ter of the cash bene­fit: if it is an over-the-coun­ter tran­sac­tion (for examp­le, goods / ser­vices are immedia­te­ly exch­an­ged for money / credit card / vou­cher), the record­ing system must ful­fill the requi­re­ments of KassenSichV. 

The record­ing sys­tems must be equip­ped with a so-called tech­ni­cal safety system(TSS)no later than 1.1.2020. This can be imple­men­ted in the form of hard­ware and chip card or as soft­ware for cloud-based sys­tems. The regu­la­ti­on is desi­gned to pro­tect against mani­pu­la­ti­on of com­pa­nies’ basic digi­tal records. Whenever cash tran­sac­tions (cash, debit card, credit card, vou­chers) are recor­ded (over-the-coun­ter busi­ness), these records must be pro­tec­ted against tam­pe­ring in com­pli­an­ce with KassenSichV.

Sto­rage in the cloud

A cloud-based imple­men­ta­ti­on of the TSS is fore­se­en by the BMF (Federal Minis­try of Finan­ce)

A real future-proof soft­ware solu­ti­on is only the one by means of the could, which makes the requi­redTSS pos­si­ble without any addi­tio­nal hard­ware. Only this way are the entre­pre­neurs able to ditch exter­nal store means, Smart­cards and POS and stay fle­xi­ble and fit for the future. 

Tech­ni­cal Direc­ti­ve: BSI TR-03153

The Federal Minis­try of Finan­ce has issued a tech­ni­cal gui­de­li­ne on the tech­ni­cal safety system (TSS) for elec­tro­nic record­ing sys­tems. Here, the gui­de­li­nes and requi­re­ments of Kas­sen­SichV are tho­rough­ly defined.

We will, for examp­le, make clear issues as the log­ging, the pre­scri­bed pro­ces­ses, the pos­si­ble sto­rage media and the data export. Fur­ther details can be found in our blog arti­cle Cur­rent Ques­ti­ons & Ans­wers on the KassenSichV.

Tech­ni­cal safety system (TSS)

The Kas­sen­SichV is based on the tech­ni­cal mani­pu­la­ti­on pro­tec­tion:
in order to find out whe­ther sub­se­quent mani­pu­la­ti­on of sales at a cash regis­ter has taken place, it must be kept tamper-proof and veri­fia­ble.
The che­cking is car­ri­ed out by means of a jour­nal, which can be expor­ted and che­cked by tax aut­ho­ri­ties with soft­ware for mani­pu­la­ti­on and mis­sing data. 

Each log­ging is pro­vi­ded with an elec­tro­nic signa­tu­re, which works on the princip­le of Block­chain. The TSS records every rele­vant ope­ra­ti­on in the record­ing system. The recor­ded data is cryp­to­gra­phi­cal­ly signed. Thanks to these signa­tures, it can be deter­mi­ned at any time that the exis­ting data has not been changed.

Cer­ti­fi­ca­ti­on of the tech­ni­cal safety system (TSS)

The requi­re­ments for the com­pon­ents SMAERS (Secu­ri­ty Module App­li­ca­ti­on for Elec­tro­nic Record Kee­ping System) and CSP (Cryp­to­gra­phic Ser­vice Pro­vi­der) are spe­ci­fied by pro­tec­tion pro­files. Com­pli­an­ce with the requi­re­ments for each com­po­nent is ensu­red in the course of certification.

An eva­lua­tor (a com­pa­ny accredi­ted by the BSI) checks the com­pli­an­ce of the pro­tec­tion pro­files for the com­pon­ents. The eva­lua­ti­on report is then for­war­ded to the BSI for veri­fi­ca­ti­on. Once the TSE has been cor­rect­ly imple­men­ted in accordance with the app­li­ca­ble requi­re­ments, it is cer­ti­fied. The BSI issues the cer­ti­fi­ca­ti­on. This must be rene­wed every five years.

Com­pon­ents of a TSS

The TSE pro­vi­des the inter­faces for record­ing tran­sac­tions and expor­ting the secu­red data. With the com­pon­ents SMAERS and CSP the data is cryp­to­gra­phi­cal­ly signed and thus pro­tec­ted against later mani­pu­la­ti­on. An ascen­ding signa­tu­re coun­ter as well as a tran­sac­tion coun­ter also pre­vents the “disap­pearan­ce” of some record­ings, as these gaps can be detec­ted automatically.

SMAERS (Secu­ri­ty Module App­li­ca­ti­on for Elec­tro­nic Record Kee­ping Sys­tems): The secu­ri­ty module pre­pa­res the data to be secu­red within a tran­sac­tion and com­mu­ni­ca­tes direct­ly with the CSP to sign the data to be secured.

CSP (Cryp­to­gra­phic Ser­vice Pro­vi­der): The sto­rage medium gene­ra­tes the signa­tures of the data to be secured.

The requi­re­ments for the modu­les were deve­lo­ped by the BSI (Federal Office for Infor­ma­ti­on Secu­ri­ty) and publis­hed in gui­de­li­nes and pro­tec­tion profiles.

Com­pon­ents of the TSS: SMAERS

One com­po­nent of the TSE (tech­ni­cal secu­ri­ty device) is the SMAERS (Secu­ri­ty Module App­li­ca­ti­on for Elec­tro­nic Record Kee­ping System) com­po­nent. It is a secu­ri­ty module that pre­pa­res the data to be secu­red within a tran­sac­tion. This module must be inte­gra­ted into the taxpayer’s cash regis­ter system.

The SMAERS com­po­nent must be ope­ra­ted on the record­ing system, the ERS (Elec­tro­nic Record Kee­ping System). The data comes from record­ing sys­tems and their input devices such as a key­board or an app on a tablet. In the signa­tu­re pro­cess SMAERS and CSP talk to each other. The BSI (German Federal Office for Infor­ma­ti­on Secu­ri­ty) cer­ti­fies com­pon­ents such as SMAERS accord­ing to spe­ci­fic pro­tec­tion profiles.

Com­po­nets of the TSS: CSP & CSP‑L

A secu­ri­ty com­po­nent of the TSE is the CSP (Cryp­to­gra­phic Ser­vice Pro­vi­der). This is the signa­tu­re unit which uses cryp­to­gra­phic pro­ce­du­res to pro­cess the data to be secu­red accord­in­gly. This pre­vents unde­tec­ted mani­pu­la­ti­on. In the signa­tu­re pro­cess SMAERS and CSP talk to each other via secure channels.

High per­for­mance signa­tu­re units are defi­ned via the pro­tec­tion pro­fi­le of the CSP‑L. These are spe­cia­li­zed server sys­tems in highly secure data centers.

In con­trast to the CSP‑L, a CSP is usual­ly a chip that cannot be ope­ra­ted effi­ci­ent­ly in a net­work. A CSP chip is mainly sui­ta­ble for indi­vi­du­al cash regis­ters. The net­work-capa­ble vari­ant of the CSP‑L was deve­lo­ped to be scala­b­le through clus­te­ring, to enable a higher data through­put and to gua­ran­tee higher reliability.

Both vari­ants are defi­ned by pro­tec­tion pro­files of the BSI (Federal Office for Infor­ma­ti­on Security).

What is a pro­tec­tion profile?

The BSI (Federal Office for Infor­ma­ti­on Secu­ri­ty) spe­ci­fies in pro­tec­tion pro­files which tech­ni­cal requi­re­ments must be met in order to achie­ve the goal of the Kas­sen­SichV. The pro­tec­tion pro­files descri­be secu­ri­ty objec­ti­ves and requi­re­ments for secu­ri­ty func­tions of the com­pon­ents. Howe­ver, the pro­duct-spe­ci­fic con­cretiz­a­ti­on is car­ri­ed out by the manufacturer.