Independent Singapore VCC guidance
Direct answer
Recertify a VCC investor portal by starting from the portal and identity-provider account population, not from an old approval list. Match every active user to a current person, organisation, role, VCC and sub-fund purpose. Require an owner to confirm the minimum functions and data needed, challenge privileged and bulk-export rights separately, then remove or suspend anything unsupported. The review closes only when changes are independently checked, failed access is tested where practical, and unresolved exceptions have an owner, safeguard and expiry.
At a glance
- Reconcile system accounts to real identities before asking owners to approve access.
- Review data scope and transaction capability separately from simple account existence.
- Treat privileged, delegated, shared and bulk-export access as distinct risk decisions.
- Retain execution evidence, not only an approval spreadsheet.
Who this is for
- VCC managers, administrators and portal owners reviewing investor, delegate, adviser and internal-user access.
Important exclusions
- A penetration test or a replacement for incident response when unauthorised access is already suspected.
Build the population from live systems
Export active, suspended, pending and privileged accounts from the investor portal and any connected identity service. Add service accounts, administrator consoles, application programming credentials and users created through a provider help desk. Reconcile that list to the current investor register, authorised-contact records, staff roster, provider team list and recent joiner, mover and leaver activity. The purpose is to find accounts that an approval spreadsheet no longer shows, as well as approved people whose role or organisation has changed. Preserve the extraction date and source so later reviewers can distinguish a missing user from an account added after the review population was fixed.
Sources: Monetary Authority of Singapore · Personal Data Protection Commission · Monetary Authority of Singapore| Population slice | Evidence to compare | Typical challenge |
|---|---|---|
| Investor and beneficial-owner users | Current investor and authorised-contact records | Is the user still connected to the correct investor and share class? |
| Delegates and professional advisers | Current delegation, mandate or written authority | Does the delegate still need direct access rather than supplied reports? |
| Manager and administrator users | Role roster and process responsibility | Is access limited to the VCC and functions actually supported? |
| Privileged and service accounts | System ownership and technical purpose | Can the privilege be reduced, time-bounded or replaced with named access? |
Related guidance: VCC mandate team-member offboarding controls
Translate roles into minimum entitlements
A role name such as investor, operations or administrator is not enough. Break access into view, upload, amend, approve, transact, impersonate, export and administer capabilities. Map each capability to the data objects it can reach, including identity documents, bank details, tax forms, capital activity, statements and messages. For an umbrella VCC, inspect whether the entitlement is confined to the intended sub-fund and investor relationship. A user who needs statements may not need source documents, other investors, bulk downloads or instruction changes. Record the business outcome that would fail if access were removed; vague convenience is not a sufficient purpose for sensitive or powerful rights.
Sources: Monetary Authority of Singapore · Personal Data Protection Commission · Monetary Authority of SingaporeEntitlement challenge questions
- The user identity is unique, current and linked to a verified organisation or investor relationship.
- The role supports a named task that the user still performs for the relevant VCC or sub-fund.
- Visible data is limited to the investor, share class and period needed for that task.
- Upload, amendment, approval and transaction rights are separated unless a documented role needs them together.
- Bulk export, impersonation and administration functions have a specific owner and stronger review evidence.
- Authentication and recovery routes do not rely on a departed employee, shared mailbox or uncontrolled device.
Related guidance: secure investor-data transfers between providers
Route approval to an accountable owner
Send each entitlement to an owner who understands both the user relationship and the affected data or action. The portal operator can explain technical rights, but should not approve its own continuing need for powerful access. Investor-facing access may need confirmation from the relationship owner, while operational and privileged rights need process or system ownership. Use positive approval for sensitive rights and treat silence as no evidence. If an owner cannot be identified, suspend the right where safe or place it into an exception route. Separate the person preparing the population from the person approving high-impact entitlements so that omissions and convenient carry-forwards can be challenged.
Sources: Monetary Authority of Singapore · Monetary Authority of Singapore · Monetary Authority of SingaporeApproval routing decision
- Identity unclearSuspend or contain the account, verify the person and organisation, and do not let an old display name stand in for identity evidence.
- Purpose endedRemove the entitlement and record the business event, affected access objects, change ticket and completion result.
- Purpose continuesApprove only the minimum current functions and data scope, with separate treatment for privileged or export capability.
- Owner disagreesEscalate the disputed right to the data or process owner and retain the safest interim access state.
- Temporary needApply a bounded start, expiry, activity limit and review trigger instead of granting an indefinite exception.
Execute changes and prove the result
Convert every remove, reduce, retain and suspend decision into a controlled change. Capture the prior and approved state, the implementer, completion time, affected groups and any dependency such as single sign-on, mailing lists or document repositories. A screenshot of an approval does not prove that the portal changed. Re-export the account and entitlement state, compare it with the approved result and sample removed rights by attempting the relevant route without exposing live data. Confirm that local portal accounts were not left active when central access was removed. Where a provider executes changes, require machine or ticket evidence that identifies the exact account and entitlement rather than a general statement that the review was completed.
Sources: Monetary Authority of Singapore · Personal Data Protection Commission · Monetary Authority of SingaporeControlled execution sequence
- FreezeRecord the approved decision set and prevent informal additions from being hidden inside the recertification work.
- ChangeImplement removals and reductions through named tickets with the prior state and affected access objects attached.
- ReconcileCompare a fresh system export with the approved state and investigate every difference, failure and unplanned addition.
- TestSample high-risk removals and downgraded roles to prove that restricted functions and data can no longer be reached.
- CloseRetain approval, execution and verification evidence together, then assign any unresolved exception and expiry.
Related guidance: personal data breach response for a VCC
Close exceptions without hiding residual access
An access review is incomplete when failed removals, disputed owners or unavailable users are moved to a comments column and forgotten. Create an exception record describing the current entitlement, data and actions exposed, reason it cannot yet be corrected, interim safeguard, monitoring, owner and expiry. Consider disabling transaction or export capability while a lower-risk viewing need remains unresolved. Review recent portal activity for accounts whose purpose is doubtful, especially unusual downloads, access outside the expected relationship or repeated recovery changes. Report the outcome by removed, reduced, confirmed and unresolved rights, not by a completion percentage that treats every entitlement as equal. Feed recurring causes into onboarding, role design and provider controls.
Sources: Monetary Authority of Singapore · Monetary Authority of Singapore · Personal Data Protection CommissionRelated guidance: core fund accounting system change control
Frequently asked questions
Should inactive portal accounts be excluded from the review?
No. Inactive, suspended and pending accounts can still reveal orphaned identities, weak recovery routes or rights that may be reactivated. Include them in the population, decide whether they should remain recoverable and retain evidence of deletion or continued containment.
Can the administrator approve all portal access?
The administrator may prepare evidence and implement changes, but business and data owners should approve continuing purpose and scope. Powerful provider access also needs independent challenge so the party operating the portal does not solely approve its own entitlements.
Is multi-factor authentication enough for investor data?
No. Strong authentication reduces the chance that a credential is misused, but it does not make unnecessary access appropriate. The review must still test identity, business purpose, VCC and sub-fund scope, functions, data objects and recovery routes.
How should shared accounts be handled?
Replace shared accounts with named identities where feasible. If a technical dependency prevents immediate removal, document the owner, purpose, credential control, activity logging, restricted capability, monitoring and expiry, then track the replacement as an open exception.
What proves that recertification is complete?
Completion evidence links the fixed account population, owner decisions, change records and a fresh system export. High-risk removals should be sampled, differences resolved and every residual right placed under a time-bounded exception with an accountable owner.
Official sources and further reading
- Risk Management Practices for Fund Management Companies (Monetary Authority of Singapore)
- Technology Risk Management Guidelines (Monetary Authority of Singapore)
- Guide to Data Protection Practices for ICT Systems (Personal Data Protection Commission)
- Understanding VCC Features, Eligibility and Requirements (Accounting and Corporate Regulatory Authority)
- Guidelines on Individual Accountability and Conduct (Monetary Authority of Singapore)
Discuss a Singapore VCC structure
For help coordinating a Singapore VCC setup or corporate administration, contact Raffles Corporate Services.
General information only. This article is not legal, tax, regulatory or investment advice and does not imply affiliation with or endorsement by ACRA, MAS or IRAS.