4. Enabling Auto Authorization
This chapter contains the following sections:
- Section 4.1, "Normal Process of Authorization in System"
- Section 4.2, "Auto-authorization"
- Section 4.3, "PIPA Audit Log"
4.1 Normal Process of Authorization in System
Most of the information that you enter in to
the system needs to be authorized to be effective. Except for the static information that you typically enter in to the system only once, all other information must be authorized. Authorization is required for all maintenance as well as transactional information in the system.
When you enter information related to any of these events into the system, the record that is initially saved when you complete the data entry is retained in the system as unauthorized information, which must be subsequently authorized to become effective.
Usually, authorizing information in the system is an activity that follows a maker-checker concept, i.e., the user that enters the information must be necessarily different from the user that authorizes the information. Therefore, whereas one user group will have access to functions that involve entering information into the system, a different user group has access to the functions that involve information authorization, and there is no overlap of access privileges.
4.2 Auto-authorization
This section contains the following topics:
- Section 4.2.1, "Auto-authorization Features in System"
- Section 4.2.2, "Using Auto-authorization Feature"
- Section 4.2.3, "Operations on Auto Authorization Records"
4.2.1 Auto-authorization Features in System
In some environments, the user that enters the information needs to be able to authorize it simultaneously. In such cases, the maker-checker concept leads to unnecessary delegation of activity, which is undesirable. This means that in such an environment, the user that enters the information must, on saving the entered record, be able to authorize the record. For such environments, the auto-authorization function is provided by the FC-IS system. When this function is used, the Save operation in any screen that involves data entry (apart from static information screens) will also invoke and perform the authorization for the records that have been entered.
It is possible to be selective about the business functions for which you need to use the auto-authorization feature. This means that you can enable the auto-authorization feature for the functions for which you require simultaneous authorization on saving the record, and you can keep it disabled for others, allowing them to go through the normal maker-checker process of authorization.
The following features comprise the auto-authorization facility in the system:
- The user administrator users can map the business users to the menu items, and make auto-authorization feature allowable for any business user – menu item mapping. All business checks, validations and processes that must be performed when the authorization happens will be triggered immediately following the use of the save operation, when the auto-authorization feature is allowed.
- The user administrator users can enable (or disable) auto authorization rights at a user group level. Any user roles and / or users associated with the user group would inherit the auto authorization privileges assigned to the user group. If a user ID is associated with multiple user roles, the most restrictive privilege assigned to the roles will be applicable.
- You can enable (or disable) the auto authorization feature for data
operations in the New mode or the Amend mode, including data entry either
for reference information, investor accounts or transactions. For transaction
entry operations in either mode, you can enable (or disable) auto authorization
for transactions involving any of the following circumstances:
- Transactions for which the transaction currency is the limit currency, and the transaction amount falls within the limit amount for that currency
- Back dated transactions
- Transactions in respect of which applicable loads have been overridden
- Transactions for which third party payment or delivery has been specified
4.2.2 Using Auto-authorization Feature
To allow the auto-authorization feature for a user group and a certain set of menu items, you must map the user groups to the menu items or the task for which auto-authorization is applicable, using the ‘Auto Auth Maintenance’ screen.
You can invoke this screen by typing ‘SMDAUTAU’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button. The screen is displayed below:
4.2.2.1 Auto Auth Maintenance Screen
You can use this screen to map user groups to the tasks for which auto-authorization is applicable. If the user administrator or the module administrator users do not maintain the setup for each of the user groups in this screen, the auto-authorization is not enabled for that user group.
4.2.2.2 Enabling or Disabling Auto-authorization for User Group
When you open the Auto Auth Maintenance screen, the auto authorization features that have been enabled for the module and the group to which the logged in user belongs, are displayed.
To amend the displayed list, click unlock icon. The screen is displayed in Amend mode, where you can make your changes. The changes you make will apply to all users and roles in the Group ID to which the logged in user belongs, for the logged in Module.
You can make changes as follows:
- To enable auto-authorization in the New mode for a task item, select ‘YES’ in the Newfield for the task item. To enable auto-authorization in the Amend mode for a task, select ‘YES’ in the Amend field for the task item.
- For transaction data entry task items, you can limit the volume of the transactions that can be auto-authorized. To setup this limit, specify the highest volume of the transaction that can be auto-authorized, in the Limit Amount field. You must also indicate the currency in which the volume you have specified is reckoned, in the Limit Currency field. You can indicate a different limit for each role or Group ID, if necessary.
- For transaction data entry, you can also enable (or disable) the auto authorization feature for transactions in the following circumstances:
- Back dated transactions. Select ‘YES’ in the Restrict Back Dated Transaction field to disable auto authorization of backdated transactions in the selected mode. Select ‘NO’ to enable auto authorization of backdated transactions in the selected mode.
- Transactions in respect of which applicable loads have been overridden. Select ‘YES’ in the Restrict Load Override Transactions field to disable auto authorization of load override transactions in the selected mode. Select ‘NO’ to enable auto authorization of load override transactions in the selected mode.
- Transactions for which third party payment has been specified. Select ‘YES’ in the Restrict Third Party Payment Transactions field to disable auto authorization of third party payment transactions in the selected mode. Select ‘NO’ to enable auto authorization of third party payment transactions in the selected mode.
- Transactions for which third party delivery has been specified. Select ‘YES’ in the Restrict Third Party Delivery Transactions field to disable auto authorization of third party delivery transactions in the selected mode. Select ‘NO’ to enable auto authorization of third party delivery transactions in the selected mode.
- When you have finished making the auto-authorization specification for a user group, click save icon to save your changes.
- When you have finished making your auto-authorization specifications for each user group in this screen, and saved your changes, the auto-authorization feature is enabled, and when the user invokes the Save operation in any of the applicable task screens, the entered records are saved as authorized records.
- To enable auto authorization for a user group other than the logged in user group, click save icon in the Auto Auth Maintenance screen. The system displays the message as “Do you want to cancel the operation?”
Click on the ‘OK’ button. The auto authorization record of the logged in user group, which was on display, is closed, and the Auto Auth Maintenance screen is opened in New mode.
Select the user group for which you want to enable or disable the auto authorization rights, in the Group ID field. Select the corresponding module in the Module ID field, and click on ‘Ok’ button.
Subsequently, proceed to set up the auto authorization rights in the same manner as described above, for the amend operation.
4.2.3 Operations on Auto Authorization Records
After you have set up auto authorization for a user group, you must have another user authorize it so that it would be effective in the system.
Before the setup is authorized, you can edit its details as many times as necessary. You can also delete it before it is authorized.
After authorization, you can only make changes to any of the details through an amendment.
The Auto Auth Maintenance screen can be used for the following operations on auto authorization setups:
- Retrieval for viewing
- Editing unauthorized setups
- Deleting unauthorized setups
- Authorizing setups
- Amending authorized setups.
To perform these operations, click on the appropriate buttons in the horizontal array of buttons in the Auto Auth Maintenance screen.
4.3 PIPA Audit Log
This section contains the following topic:
4.3.1 Uploading PIPA Audit Log
As per Article 12 of Enforcement Rules of Personal Information Protection Act which is enacted according to Article 55 of the Personal Information Protection Act (‘the Act’), the government agency or the non-government agency will have to take technical or organizational measures for the purpose of preventing personal information from being stolen, altered, damaged, destroyed or disclosed. This includes but is not limited to establishing a mechanism of auditing information security and keeping records of the use, locus information and proof.
You can log audit information to access unit holder/ customer/ transaction and balance related information. The system will store the details of data accessed by the business user for the current day. The data access log covers the following data:
- Unit Holder Account Information and change of information (amendment)
- Customer Information and change of information
- Transactions
- Unit holder balance
- Consolidated inquiry
- Unit holder income distribution setup
- Balance view through various transaction screen (through hyper links)
Audit of personnel accessing the above data will stored/ logged and the details are as follows:
- User Identification
- Access date and Time (Application date and system date)
- Operation
- Function ID accessed
- Unit holder account/ Entity ID/ Auth rep ID
- Customer account
- To unit holder account (in case of transfers)
- To Customer account (in case of transfers)
The audit log process happens for the following New/ Modify/ Query/ Delete operations for a single record and fetch a single record from summary screen and view in detail screen. You can track actions in audit log in ‘View’ mode for a specific record for:
- UH and CIF – Tracks when user views specific record.
- Transaction – Tracks when specific transaction details is retrieved
- Queries/ Reports:
- Consolidate Inquiry – Tracks when ‘Investor Fund Balance’ button is clicked for the retrieved UH Fund Balances
- Unit Holder Balance – Tracks when specific Unit holder Balances is retrieved (this includes Balance view through various transaction screen by clicking ‘View Balance’ screen)
The system uses ‘PIPA Audit log’ as part of EOD activity to extract the data logged for the current day and for the module logged.
The multi record fetched through summary screen will not be logged; but a single record selected through the summary result will record the log.
You can fetch subscription records through summary screen by selecting a single record and view the record through detail screen.
Any data viewed via Detail screen by clicking Search/ Fetch button like List of values, find UH will not be logged by the system.
Note
All queries irrespective of success or unsuccessful output will be logged as part of audit requirement.
Following are the list of function IDs impacted in the system:
Function ID |
Description |
Audit against the Operations |
UTDCUST |
Customer Maintenance -> Detail |
New/ Modify/ Query/ Delete/ Close/ Reopen |
UTDCADD |
CIF Address -> Detail |
New/ Close/ Query/ Modify/ Reopen |
UTDCFNMP |
CIF Address Fund Map -> Detail |
New/ Delete/ Close/ Authorise/Query/ Reopen |
UTDCIFLG |
Customer Log -> Customer Log |
New/ Query |
UTDUH |
Unit holder -> Detail |
New/ Copy/ Query/ Modify/ Reopen |
UTDUHBAL |
Unit Holder Balances -> Summary |
Enter Query |
UTDUHCOE |
Unit Holder Currency of Expression -> Detail |
New/ Delete/ Close/ Authorise/Query/ Reopen/ Modify |
UTDUHDEL |
Unit holder Deal -> Detail |
New/ Delete/ Close/ Authorise/Query/ Reopen/ Modify |
UTDUHIDS |
UH IDS Setup -> Detail |
New/ Delete/ Close/ Authorise/Query/ Reopen/ Modify |
UTDUHIOF |
UH IRRF Preference -> Detail |
New/ Delete/ Close/ Authorise/Query/ Reopen/ Modify |
UTDUHLOI |
UH LOI -> Detail |
New/ Delete/ Close/ Authorise/Query/ Reopen/ Modify |
UTDUHNPI |
UH NPI Preference -> Detail |
New/ Delete/ Close/ Authorize/Query/ Reopen/ Modify |
UTDUHNTX |
UH Non Tax Limits -> Detail |
New/ Delete/ Close/ Authorise/Query/ Reopen/ Modify |
UTDUHPR |
UH Portfolio Re Adjustment -> Detail |
New/ Delete/ Close/ Authorize/Query/ Reopen/ Modify |
UTDACCLS |
UH Status Change -> Detail |
New/ Delete/ Authorize/ Query/ Modify |
UTDADJ02 |
Transaction -> Adjustment Subscription |
New/ Delete/ Authorize/ Query/ Modify |
UTDADJ03 |
Transaction -> Adjustment Redemption |
New/ Delete/ Authorize/ Query/ Modify |
UTDTXN01 |
Transaction -> IPO Subscription |
New/ Delete/ Authorize/ Reverse Query/ Modify |
UTDTXN02 |
Transaction -> Subscription |
New/ Delete/ Authorize/ Reverse/ Query/ Modify |
UTDTXN03 |
Transaction -> Redemption |
New/ Delete/ Authorize/ Reverse/Query/ Modify |
UTDTXN04 |
Transaction -> Switch |
New/ Delete/ Authorize/ Reverse/Query/ Modify |
UTDTXN05 |
Transaction -> Transfer |
New/ Delete/ Authorize/ Reverse/Query/ Modify |
UTDTXN06 |
Transaction -> Block |
New/ Delete/ Authorize/ Query/ Modify |
UTDTXN07 |
Transaction -> Un-Block |
New/ Delete/ Authorize/ Query/ Modify |
UTDTXN08 |
Transaction -> Consolidation |
New/ Delete/ Authorize/ Query/ Modify |
UTDTXN09 |
Transaction -> Split |
New/ Delete/ Authorize/ Query/ Modify |
UTDTXN10 |
Transaction -> Reissue |
New/ Delete/ Authorize/ Query/ Modify |
UTDTXNEE |
Transaction -> Enrich Exchange Rate |
Query |
UTDTXNLT |
Transaction -> Light Weight Transaction |
New/ Authorize/ View/ Query |
UTDCNVTX |
Transaction -> Conversion |
New/ Delete/ Authorize/ Query/ Modify |
UTDAMT06 |
Amount Block -> Detail |
New/ Delete/ Authorise/ Query/ Modify |
UTDAMT07 |
Amount Un-Block -> Detail |
New/ Delete/ Authorise/ Query/ Modify |
UTDCOMCL |
Tax Compliance -> Classification |
New/ Delete/ Authorise/ Query/ Modify |
UTDDCTRO |
UH Dividend Component Override -> Detail |
New/ Delete/ Authorise/ Query/ Modify |
UTDFATMT |
FATCA -> Entity FATCA Classification |
New/ Delete/ Authorize/ Query/ Modify |
UTDFNBAL |
Investor fund Balance -> Summary |
Query |
UTDFNENT |
Fund Entity -> Detail |
New/ Delete/ Close/ Authorise/Query/ Reopen/ Modify |
UTDKYCCD |
KYC Chasing Details -> Detail |
New/ Delete/ Authorise/ Query/ Modify |
UTDOLT |
One Legged Transfer -> Detail |
New/ Query |
UTDPRQRY |
Back Data Propagation -> Propagation Enquiry |
Enter Query |
UTDPRTXN |
Back Data Propagation -> UT Transaction |
New/ Delete/ Authorize/ Query/ Modify |
UTDROPUT |
Back Data Propagation -> UT Propagation |
New/ Authorise/ Query |
LEDPROSI |
Back Data Propagation -> LEP Propagate SI |
New/ Delete/ Authorize/ Query/ Modify |
LEDPRTXN |
Back Data Propagation -> LEP Transaction |
New/ Delete/ Authorize/ Query/ Modify |
UTDRTAIO |
RTA Transfers -> Detail |
New/ Query |
UTDSCADH |
Share Class Adhoc Conversion -> Detail |
New/ Delete/ Close/ Authorise/Query/ Modify/ Reopen |
UTSCOINQ |
Queries -> Consolidated Enquiry |
View |
LEDPLAN |
LEP Online -> Policy |
New/ Delete/ Close/ Authorise/Query/ Reopen/ Modify |
LEDPLCES |
LEP Maintenance -> Policy Cession |
New/ Delete/ Reverse/ Authorise/Query/ Modify |
LEDPLREV |
LEP Online -> Policy Reversal |
New/ Delete/ Authorise/ Query/Modify |
LEDPLSUR |
LEP Online -> Policy Surrender |
New/ Delete/ Reverse/ Authorise/Query/ Modify |
LEDPLSWI |
LEP Online -> Policy Switch |
New/ Delete/ Reverse/ Authorise/Query/ Modify |
LEDPLTOP |
LEP Online -> Policy Top Up |
New/ Delete/ Reverse/ Authorise/Query/ Modify |
UTDATREP |
Auth Rep Maintenance -> Detail |
New/ Delete/ Authorise/ Query/ Modify |
UTDENTMN |
Single Entity Maintenance -> Detail |
New/ Delete/ Authorise/ Query/ Modify |
The SMTB_SMS_LOG and SMTBS_SMS_ACTION_LOG tables will log the audit information and hence the system will purge/ archive the data of these two data stores.
Note
After EOD, the system will store the audit logging details in PIPAAUDITPROCESSTBL. The purging will happen in PIPAAUDITPROCESSTBL table.