Policy memory has many uses. For example, if a KYC case is withdrawn and recreated due to change in the driver data, you can use the policy memory to temporarily store KYC policies and reuse them when a similar case is triggered, thus preventing the loss of valuable KYC information.

Creating records in memory

You can create a record in the policy memory by invoking the Policy Memory Creator method. This method, located in the Work- class, and uses customer ID, memory ID, and a source page as parameters. The API creates a policy memory that is uniquely identified by the customer ID and the memory ID. It is loaded with the KYC polices supplied on the source page.

The memory ID can be anything that signifies the purpose of creating the policy memory for a customer and can uniquely identify it. For example, in a complex onboarding case created for a customer, the memory ID can be set to the ID of the onbarding case, implying that all of the KYC cases created for the onboarding case will use the same policy memory identifier. At the time of retrieving records from the policy memory, the system can use the customer ID and memory ID to ensure that the KYC types stored as temporary data in one onboarding case are not picked and reused from another.

The engine does not impose any restrictions on the number of policy memories that can be created for a customer. However, for maximum reuse of the KYC policies data, it is recommended that you use one policy memory record per customer per case hierarchy.

The policy memory creator API also accepts KYC Status as parameter. This parameter can be used to denote the status of the type when the policy memory was created (for example, in initial capture, in review, and so on). The status can be used later to decide the action to be taken on the case after retrieval of KYC types from policy memory.

Accessing records in memory

You can access policy memory by invoking the D_GetPolicyMemory data page, which uses the customer ID and memory ID as mandatory parameters. Most of the time, customers prefer using the Policy Profile interface to automatically consolidate the results from the policy profile and the policy memory, instead of doing an explicit invocation to the policy memory. To get that consolidated view, you must invoke the D_GetPolicyProfile data page by passing the memory ID along with the existing customer ID parameter. If the parameter is not passed, D_GetPolicyProfile continues to present pure policy profile information. Data from policy memory is not considered and no consolidation is made).

In the process of consolidation, if a KYC type exists in both the policy profile and policy memory, then the most recently updated one is preferred, thus ensuring the latest information is on the resultant consolidated page.

The KYC engine has been updated to use this new consolidated data page in its processing. To reuse the KYC type information from the policy memory in the KYC case, you must have the system configured to use the KYC Policy Profile and the pyCustomer and PolicyMemoryID properties must be available on the work objects primary page.

Cleaning up the memory

The KYCPolicyMemoryCleaner job scheduler is configured to periodically clean up the policy memory instances form the database. By default, the system deletes the policy memories that are older than 30 day. You can configure this threshold by updating the PolicyMemoryCleanupInDays dynamic system setting).

If your implementation cannot make use of the job scheduler or you wish to cleanup the policy memories, use the CleanPolicyMemoryArchive API, present in the work class. Similar to the D_GetPolicyProfile, this API uses the customer ID and the memory ID to locate and delete the policy profiles. The method has been designed to delete only those KYC types from the policy memory that are present on the page that the API is invoked from. The API must be plugged into the KYC case flow right before the KYC type data is synchronized to the policy profile and the case is resolved. The method automatically deletes the record in the policy memory when no more KYC types are available on it.

Important rules and references