CentralPark 1.8.2611.5488 is available

You can download it here.

Release Notes: 

Improvements:

• Streamlined Manual Capture Transaction list page to be more usable and confirmed access to "Pay Beneficiary" and "Add Once Off".
• Updated required field validations on Manual capture and Beneficiary payment screens.
• Added a pop-up to show batch details for Document Creation Processes on the Run Process Screen.
• Updated the control on the Manual Capture Validations screen.
• Made CP compatible with other browsers namely Chrome and Firefox.

Bugs:

• Fixed an "object reference" bug when trying to "Import, Enrich and Validate" when there are no transactions to import, enrich or validate. 

Details:

A Usability release was done to make some improvements to screens that users used the most and add value and useful functionality to assist users in their day to day operations. 

The Manual Capture was the place where most work was done since it was a painful point for users. We tried to assist the user to logically understand what is required from them by providing a layout that is more conducive to the task and some validations that would help save time since the backend validation takes long. The idea was to try to assist the user in providing correct information so that backend validation should not have to be repeated.

Along with the items identified above certain filters got a "Show Today" option to easily and quickly filter for today's results which was a very common task performed by users. 

Introducing Transaction and Instruction hashing

The Scenario:

A nefarious user gets access to the database and changes account details or amounts for payments to be made. The Authorisers may not initially pick up that the changes have been made and allow a corrupted payment to be made. 

This has a big impact on business as payments could be erroneously made and they are very difficult if not impossible to undo. 

The Solution:

Verify that the transaction entered or the instruction created have not been tampered with during its progression through the system. 

The Motivation for the Chosen Implementation:

Hashing was chosen as the implementation since it could be implemented without undue risk to existing implementations and it could be done in a way that is entirely secure. 

Hashing is lightweight since it only requires the generation and validation of the hash at key points in the process. It does not require any changes to CentralPark's existing process only the addition of a few columns on existing tables to track the hash. This means that there is no impact on the data and structures of the data, reducing the risk of impacting existing clients' data. 

Creating the hash itself is very efficient and fast and since transaction and instruction data is already being stored the overhead of storing a few extra fields is minimal. 

An added security feature of hashing is that the "key" used in creating the hash is stored within the code, making the computing of hashes very difficult to reverse engineer since the hash does not depend solely on the data visible in the database. 

The Actual Implementation:

When a transaction enters the system via an import or a manual capture, various details of the transaction (including  specifically the account number and amount) are used to compute a unique hash value using a SHA-256 hashing algorithm. This hash is stored along with the transaction. 

Before a transaction is legitimately edited from the front end, the stored hash is validated to verify that the transaction has not been tampered with. Once the legitimate edit is done a new hash is generated for the newly set values. The edit process is logged in CentralPark's history of that transaction. 

At the point of instruction creation the transaction used to create the instruction has its hash validated. This ensures that the transaction was not tampered with as it was processed through the system. The resulting instruction is created along with a hash of its values. This is an 'atomic' step (1 step process) in which the transaction is validated and the instruction and its hash are created. 

Finally, before the instruction is incorporated into an Instruction Document, to be sent to the bank the instructions to be used in the document are all validated against their hashes to confirm that they were not tampered with. 

A comprehensive list of tests were done to validate the integrity of the hashing implementation. Embedded below is a document that describes the tests carried out. These tests were run in an attempt simulate what a user may do to try to push through an invalid transaction. 

The Exceptions:

If a hash validation fails for a transaction or instruction, the running process will be aborted as a failure and the offending transactions or instructions will be logged in an error table. Exceptions can then be viewed via a new screen in the Admin menu called Hash Validation Failures.

The Performance:

Numerous tests were done on batches from 10 - 50000 - 200 000 transactions that were Imported and processed through to an Instruction Document being created. The performance degradation in labs tests was approximately 12% on batches of 50 000 and 6% on Batches of 200 000.

CentralPark 1.8.2605.5471 is available

You can download it here.

Release Notes:

• Added Transaction and Instruction Hashing.