Correct the Register

Correct the Register (a.k.a. CTR) is the Verne functionality that allows for an ad-hoc correction of registry data that has been previously approved. Changes are carried out via CTR due to erroneous data entry. The goal is to ensure that the data recorded on the register is correct, even when viewing historical information.

Data on the register is created and maintained by means of applying business services. Each business service activates a corresponding service transaction. This changes entity data that is displayed on the register (e.g. view entity details, extracts, certificates, search) and makes filing documents available in the filing history for users to review. If any errors were made or any information was missed when applying a business service, a privileged user is able to correct the erroneously applied data.

Example

An entity was renamed from Grey Sky to Blue Sky. The entity owner recorded this change on the Register on 15 January 2018 and modified the name from Grey Sky to BlueSky, missing the space. This error wasn’t noticed until 10 March 2018. The owner contacted the registry manager and requested a correction of the entity name from BlueSky to Blue Sky effective 15 January 2018.

The name BlueSky should have never have existed on the register. Making the correction via the normal maintain entity name service would create a record for the incorrect name BlueSky and the register would show the history of the entity name changes from original Grey Sky to BlueSky and then from BlueSky to Blue Sky. By using CTR the error is corrected without BlueSky being held as a historical entity.

Audit trail

A full audit trail of corrections is recorded as part of any Correct the Register activity. Changes made via Correct the Register services never generate watchlist events or correspondence. A Filing Notice of Rectification is created as a result of the correction, it contains details of the change.

Before a user can proceed with correcting the entity data or filings, they are requested to provide details of who triggered the change to ensure an adequate audit trail is maintained. During this process, the user is able to specify the following:

• the reason for the correction,
• correction supporting documents,
• ‘Notice of Rectification’ filing settings, such as visibility, display date and filing name.

Correct the Register Features

For each of the root domain (i.e. entity type) there must be two business services that allow for data correction:

Correct Transaction

This feature allows to effect a change on the Register where a business service instance has been approved and applied, however was later discovered to contain some errors or where the standard settings applied by default need to be changed for this service instance.

The Correct Transaction form contains a series of tabs where an appropriately privileged internal user is able to:

• provide details about this correction: who, why and when requested the correction
• update entity details to represent the correct state of entity data (form is specific to the selected entity type, loaded with entity details from the selected entity version)
• updated transnational details associated with this specific transaction to represent the correct state of service data (list of service instance domain fields specific to the selected transaction, as well as presenter instance domain fields)
• update filing settings for all of the filings associated with this transaction (filing name, filing date, filing visibility) or remove unnecessary filings
• provide notice of rectification settings: filing name, filing visibility, filing date
• preview notice of rectification filing that is going to be recorded on the register should the user apply the changes
• preview filings for this transaction should the user apply the changes

Insert Transaction

This feature allows to effect a change on the Register in the following scenarios:

• The change relates to a historical submission that was missed by mistake. In other words transaction relates to a date in the past and therefore cannot be just simply done via a normal maintain service or by correcting one of the existing transactions, as firstly it will display the wrong effective dates, and secondly, there could be other subsequent transactions already applied and the order will not be correct.
• This service can also be used as a “catch all” maintain service that can be applied as of the current date, as opposed to correcting the current version of an entity and therefore affecting the last approved transaction.

The Insert Transaction form contains a series of tabs where an appropriately privileged internal user is able to:

• provide details about this correction: type of the new transaction, new transaction effective date, who, why and when requested the correction
• update entity details to represent changes introduced by this new transaction (form is specific to the selected entity type, loaded with entity details from the entity version that was effective on the selected transaction date)
• provide transnational details associated with this specific transaction (list of service instance domain fields specific to the selected transaction, as well as presenter instance domain fields)
• provide filing settings for all of the filings associated with this transaction (filing name, filing date, filing visibility)
• provide notice of rectification settings: filing name, filing visibility, filing date
• preview notice of rectification filing that is going to be recorded on the register should the user apply the changes
• preview new filings for this transaction should the user apply the changes

Correct the Register Scenarios

Correcting and inserting transactions enables the registry staff to achieve the following outcomes:

A	Correct current and historical entity data to change information displayed on the view entity screen, visible in the search results, used in certificates and extracts, and displayed in the body of the filings.
B	Correct the content of the filings to change information that is not related to the entity data, such as presenter details, application supporting information and uploads, and correction description.
C	Correct the name of the filings displayed in the filings history screen.
D	Correct the visibility of the filings displayed in the filings history screen to ensure only users with correct privileges can see the filing.
E	Change the display order of the filings in the filings history screen (i.e. reorder).
F	Effect a change to the entity that relates to a historical transaction that was missed by mistake.
G	Effect any ad-hoc change to the entity details as of the current date. As a result a proper filing gets created and changes are recorded in a new entity version.
H	Update entity data bypassing standard validation business rules.
I	Delete a filing generated by a service / Add a filing that a service is configured to generate, but did not generate

Below are the most common scenarios where Correct the Register features can be applied:

ervice contains an error Capabilities used: A and B	An approved transaction might contain errors that were not noticed at the time the service was submitted and approved. As a result entity data or transaction details on the public Register do not reflect the actual state. For example, a new director has been appointed and her legal name was spelt as Anna-Maria, rather than the correct form of Anna Maria. The typo was not noticed until a few months afterwards. The director requested that her name be corrected as of the date she was appointed.
Incorrect filing visibility Capabilities used: D	Filing visibility rules are defined for each business service in the filing instructions. When standard rules do not apply, the registry staff need to change the filing visibility. For example, a user uploaded a document with private information and it should remain on the register as a part of the filing however it should be hidden from the casual users. The registry staff hides the filing from external users without authority to protect sensitive information.
Incorrect filing order Capabilities used: E	Filings are ordered based on the date the corresponding service was applied to the register. In rare cases, this order needs to be altered. This does not change the actual date of the service activation or change the historical order of entity versioning. This just affects ordering of the filing records.
Inherited error Capabilities used: A	If errors were made in one of the previous transactions, then all of the subsequent transactions will inherit those errors by copying a full snapshot of entity data. When corrections are made to the previous transaction, registry staff should manually correct any following transactions that inherited this error.
Missed application Capabilities used: F and G	Sometimes changes that should have been applied to the Register were missed by mistake. Other transactions had taken place since the date the missed transaction was submitted. Simply using corresponding online business service to enter changes of the missed transaction will not achieve desirable outcome of putting them in the right point in time in the past between the other existing transactions. For example, the entity trading name was changed twice, from original “BlueSky” to “Blue-Sky” and finally to “Blue Sky”. An application to change from “BlueSky” to “Blue-Sky” was submitted by mail and was lost. Then an online service was used to change from “BlueSky” to “Blue Sky”. And only a few months later it was discovered that “Blue-Sky” was never recorded on the public register. The entity requested registry staff to retrospectively effect the change.
Application to be withdrawn Capabilities used: A, D or and I	The Registrar is able to withdraw an application from the Register if it was applied to an entity by mistake or due to fraud. This can be achieved via Correct the Register capability by restoring the state of an entity prior to the wrong submission and hiding or removing the associated filings. – Firstly, the Registrar will need to correct entity data in order to ‘undo’ the changes introduced by the wrong submission. This will need to be done to all entity transactions starting from the one where wrong/fraudulent changes were introduced and all the way up to the most recent (current) transaction. – Secondly, the Registrar will need to either hide the corresponding service filing (by changing its visibility to ‘internal’) or by removing the filing from this transaction, so that public users do not have visibility of the wrong/fraudulent submission. The audit trail about the wrong/fraudulent submission will remain on the Register in the form of a record under Filings/All tab showing that a transaction was originally lodged and approved but was later corrected. It will also be clear from Filings/All tab if the filing was kept but made internal or if it was removed, as it will be missing. Note, that the content of the original filing (if it was kept) and the content of the transaction record from the Filings /All tab will be affected by the correction and will no longer show the original submission details. However, notice of rectification filing will display all the details of the original wrong submission and how they were ‘undone’ to restore the correct entity data.
Retrospective change Capabilities used: F and G	In some jurisdictions, courts can order for an entity to retrospectively be changed in the register. For example, a court order has been issued to cease a fraudulent director from the register as of a specified date in the past. Registry staff will insert the transaction using service type Maintain Directors. The fraudulent director will be ceased via this service. Any subsequent transactions will also be corrected to reflect that the director is cease.
Ad hoc change Capabilities used: G	There can be entity details that are so minor that it is considered not practical to deliver special maintenance service to change the values. Where such entity details need to be changed that do not have a corresponding online maintain service, registry staff can insert a new ad hoc transaction. For example, in jurisdiction X, a company can be a registered charities provider. In such cases, a Charities Registration number should be displayed and available for editing. Only 1% of companies are actually registered with the charities services and registry staff only receive 10 new registrations per year. In this case, the Charities Registration Number filed is added into the entity data set by registry staff. A company director submits a request on paper and registry staff makes the change on the register by inserting a new ad hoc transaction.
Correction contains error Capabilities used: B.	When applying the correction, an internal user might make a mistake or miss some information that was meant to be put into correction description. For example, the director requested to correct her name from Anna Maria to Anna-Maria and submitted a copy of her passport. Internal user applied the correction and uploaded the wrong file into the Supporting Documents field that was then displayed in the Notice of Rectification Filing.
Data migration error Capabilities used: A.	Legacy data was migrated into the register with errors that were not identified during analysis and data cleansing. CTR can be used to correct or cleanse any data that is found to be migrated with incorrectly.
Entity type conversion Capabilities used: A, B, C, D, E	Some jurisdictions allow entities to change their entity type, that frequently means that the entity needs to provide additional details that were not applicable to its previous entity type. If this does not happen very often, clients prefer not to invest into a specific service to enter missing data, instead they can use CTR to fill in the gaps once entity type conversion has been applied by another service.
Piece of data cannot be updated via maintain service due to violation of standard validation rules Capabilities used: H.	Verne business services that create and maintain an entity are usually design to ensure enforce a lot of business validation rules to ensure register integrity. However there are rare exceptions to most of the rules, to enable Registrar to bypass rules where needed CTR forms usually “relax” validation rules that would not cause system errors. Relaxed validation of mandatory fields  Majority of the fields that are normally mandatory in the registration / maintain services can be made optional in CTR. Mandatory fields that are made optional in CTR will still trigger validation, however, the message will be displayed as “info” allowing correction to be submitted. Conditionally mandatory fields might not display “info” and will be fully optional in CTR if the condition is complex. Exceptions include those fields that could cause system errors if not populated, so those should never be made optional in CTR. Example of use:  – This can allow jurisdictions to correct migrated entities that normally do not have full set of data. – In some exceptional cases person might not have a first name and it needs to be left blank Relaxed validation of business rules All validation business rules that are normally enforced in registration / maintain services and generate error messages can be relaxed in CTR. Relaxing a rule means that the validation associated with it does trigger but generates an “info” message instead, allowing correction to be submitted. For example, when an entity is corrected via CTR, the following rules can be relaxed – physical address can contain PO Box words in it, – local company can have zero resident directors, – entity name can be identical to another active name, – entity name can contain the wrong suffix or contain no suffix  – email address can be entered in a wrong format (allowing for a new domain to be entered that fails normal validation). Normally all of these scenarios will cause validation errors preventing maintain service from being submitted. Exceptions include those validation business rules that could cause system errors if not populated. The following validation rules will continue being enforced: – max characters restrictions on all of the fields Each project and registry template will need to specify the business rules that are to be relaxed in CTR  – refer to business service documentation

Cascading corrections

In the event that a historical (previous) transaction is corrected, it should be noted that a subsequent cascading of that correction through later transactions to the Current will not occur, given that this has the potential for unplanned overwrites of data in later snapshots. As an example, if the Company Name was amended in a conventional manner in the fourth snapshot of data from ‘B’ to ‘C’ and a correction was then applied to the second snapshot because ‘B’ was in fact wrong (it should have been ‘A’ in the first place), a cascade would overwrite the change in the fourth snapshot from ‘C’ to ‘A’ which would be wrong. The effect of this condition is that any corrections that should in fact cascade need to be made manually and individually to each snapshot that inherited the error.