CentralPark 1.10.2823.6184 is available

You can download it here.

Release Note:

Features:
* Added validation on 'Source Transaction Type' (ZEN 729).
* Added new 'Batch Views' functionality to the following pages:
 - 'Create Instructions' page.
 - 'Release Instructions' page
 - 'Create Instruction Documents' page
* Added new Bank Confirmation Emulator functionality for the following response files:
 - ABSA Host to Host: Confirmation and Unpaid.
 - CABS : CABS Confirmation ( Zimbabwe)
 - CSZv3: CSZv3 Response ( Zimbabwe)
 - Downtown Cheque: Confirmation and Unpaid.
 - FNB PACS: FNB Hash, ACB Load, TS70, ACB Error
 - FNB eForex: FNB eForex feedback and FNB Forex rejects
 - Nedbank CPS: ACK, Unpaid, NAEDOS, Simple ACK
 - Standard Bank BEFT: Audit, Unpaid
 - Standard Bank CATS: Audit, Unpaid
 - Standard Bank CATS Host to Host SSVS V1: Unpaid, Audit, Interim Audit, Vet.
 - Standard Bank NAEDO: Interim Audit, Vet, Response, Dispute
* Added new instruction types:
 - CSZSFI Ver4 (2009) instruction document and response file (ZEN 753)
 - CABS instruction document and response file (ZEN 755)
 - Paynet Manual Upload (ZEN 754)
 - ABSA BI Online Batch Import

Improvements:
* Improved performance on 'Instruction Document Creation' process. (ZEN 747)
* Added optional 'General Ledger Reference'.
* Improvements to instruction Types:
 FNB PACS
 - added option to map 'User Reference'.
 - change to support 'BankId' larger than 3 characters.
Standard Chartered
 -  change to allow blank value for Standard Chartered Debit Bank ID
* Improved process of sending web service response messages (ZEN 689)
* Improvements to process log
 - Added summary to default view
 - Added child details to summary.
* Added 'transaction rejection' process to the process queue to prevent transactions
   being rejected whilst they are part of an 'instruction create' process. (ZEN 604)
* Improvements to  'Create Instruction Document Page'
  - Added logic to enforce document type selection
  - Added option to 'Create documents for All'
* Moved 'Instruction Batch Id' to second row of filter grid.
* Added 'Amount' to 'Release Instructions' page filter grid.

Bug fixes:
* Fixed bug on 'Process Log' page. (ZEN 777)
* Fixed bug in new extended General Ledger functionality - capturing General Ledger
   codes now optional when 'General Ledger Tracking' enabled.
* Increased relevant 'MatchingData' field sizes to varchar (100).
* Fixed bug with 'Windows authentication' and unauthorised users. (ZEN 778)
* Fixed bug in 'Instruction Document Creation Process'.
* Fixed bug in 'Recreate instruction document via a process definition'.
* Fixed bug in 'Event/Action mapping' page.
* Fixed bug in 'Import Succeeded' Action/Event Logic.
* Fixed bug to prevent duplication of process definitions. (ZEN 815)
* Fixed ImportCreditGLAccount to have correct length.
* Fixed ImportDebitGLAccount to have correct length.
* Fixed ABSA Host to Host sequence numbers.
* Fixed 'Instruction Create' consolidation logic.

CentralPark 1.8.2615.5499 is available

You can download it here.

Release Notes: 

Improvements:

* Added caching of Script Validations in the front-end and service to improve validation performance. 

Description:

This functionality was tested in a client environment and it made a big difference. A single reported result was process validations that took 10 minutes previously now take less than 1 minute.

The idea behind the change is that we keep a copy of the compiled version of the script validation in a cache. This will save time when executing the validation since we do not have to compile it every time we need it. 

Essentially the way it works is:
- When we need to run a validation we will check the cache
- If the validation does not already exist in the cache
    - we compile it and
    - add it to the cache
- We then load the precompiled version from the cache and run it
- When a validation is changed we update the version in the cache when the user saves the changes
- If a validation is set inactive or deleted we remove it from the cache
- The cache will have the latest versions of the validations precompiled and ready to be used, thus saving compilation time on every use. 

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.

CentralPark 1.8.2602.5456 is available

You can download it here.

Release Notes:

• Improved Duplicate Validation performance.