4 ms·

I have a tangential question to this whole debacle: I'm a developer who worked on a lot of safety critical stuff. I think I know a lot about that. But never wor

I have a tangential question to this whole debacle: I'm a developer who worked on a lot of safety critical stuff. I think I know a lot about that. But never worked with "money stuff". What are the best practices in this regard? I understand this whole thing is not just a software development failure. But it also feels as if the Fujitsu developers had done a better job we wouldn't be having the whole debacle. So what are the best practices with a system like this? Are there good and practical books for example on the topic?

pjc50 3y ago
A good start might be the French "NF525" law, which lays down legal standards for how cash registers should work. https://www2.ikosoft.com/en-gb/all-knowledge-about-the-nf525-standard-for-cash-register-software/ https://www2.ikosoft.com/en-gb/all-knowledge-about-the-nf525... / https://www2.ikosoft.com/en-gb/cash-security-software-how-to-comply-with-standards-nf525/ https://www2.ikosoft.com/en-gb/cash-security-software-how-to... "Any software with nf certification must not allow any concealment of data essential for VAT assessment. It must be equipped with a system for identification and tracing of all processes and information relating to collections. Concerning the registration, the security is done by electronic signature. All information recorded in the cash register system cannot be modified or deleted. Errors and returns are automatically considered as new transactions. As regards the retention of data, the minimum period imposed by the standard is six years. Furthermore, during a tax audit, an archiving system must facilitate the interventions of the tax authorities, by quickly restoring the data necessary for the calculation of VAT. Note that archiving is systematic before any purging procedure. This rule ensures that the data is available at each intervention of the administration’s agents." It's perhaps a bit more like signed git commits than blockchain; the requirement is that every transaction be signed and immutable. If "corrections" are required, the correction has to be appended to the log leaving the original in place. I believe there's also a requirement to feed all this receipt data to the tax authorities.

pjc50 3y ago

A good start might be the French "NF525" law, which lays down legal standards for how cash registers should work. https://www2.ikosoft.com/en-gb/all-knowledge-about-the-nf525-standard-for-cash-register-software/ https://www2.ikosoft.com/en-gb/all-knowledge-about-the-nf525... / https://www2.ikosoft.com/en-gb/cash-security-software-how-to-comply-with-standards-nf525/ https://www2.ikosoft.com/en-gb/cash-security-software-how-to... "Any software with nf certification must not allow any concealment of data essential for VAT assessment. It must be equipped with a system for identification and tracing of all processes and information relating to collections. Concerning the registration, the security is done by electronic signature. All information recorded in the cash register system cannot be modified or deleted. Errors and returns are automatically considered as new transactions. As regards the retention of data, the minimum period imposed by the standard is six years. Furthermore, during a tax audit, an archiving system must facilitate the interventions of the tax authorities, by quickly restoring the data necessary for the calculation of VAT. Note that archiving is systematic before any purging procedure. This rule ensures that the data is available at each intervention of the administration’s agents." It's perhaps a bit more like signed git commits than blockchain; the requirement is that every transaction be signed and immutable. If "corrections" are required, the correction has to be appended to the log leaving the original in place. I believe there's also a requirement to feed all this receipt data to the tax authorities.