Independent Singapore VCC guidance
Direct answer
Treat a bank-mandate change as an access migration, not a signature form. Freeze the current authority and entitlement inventory, approve the target state by account and sub-fund, submit one controlled instruction set, then test additions, removals, limits and workflows. Close only when former access is disabled, live payments follow the approved route and evidence is retained.
At a glance
- Inventory legal authority, bank mandates and digital entitlements separately.
- Approve the target state by account, sub-fund, payment type and limit.
- Avoid removing all working access before replacement access is tested.
- Reconcile bank confirmation to the approved instruction, not to the request email.
- Retain proof that former users and devices can no longer act.
Who this is for
- VCC teams changing bank signatories, approval workflows, users, devices or payment entitlements.
Important exclusions
- A suspected fraud or unauthorised transfer, which requires immediate bank escalation and situation-specific professional advice.
Define the change event precisely
A bank-mandate project can be triggered by an officer change, provider handover, role redesign, leave arrangement or control remediation. Those events are not identical. ACRA separately requires VCC information and officer records to stay current, while the bank maintains its own contractual mandate and digital-access records. Build one event file, but do not assume that updating one system automatically updates another.
Sources: ACRA · ACRA · MAS| Layer | Question to answer | Typical evidence | Control risk |
|---|---|---|---|
| Governance authority | Who may approve the mandate design? | Resolution, delegated-authority record and conflicts check | Instruction lacks valid approval |
| Contractual mandate | Who may sign or authorise with the bank? | Current bank mandate and accepted change form | Bank record differs from internal authority |
| Digital entitlement | What can each user view, create or release? | User-role export and workflow map | Hidden access survives the mandate change |
| Operational dependency | Who can run critical payments during transition? | Cutover plan, backup owner and test script | Control change creates a payment outage |
Freeze the current access inventory
Before requesting any change, capture the current state directly from bank records and controlled internal records. Include every account, sub-fund designation, currency, user, device, token, approval group, payment type, viewing right, template, standing instruction and notification destination. Compare that inventory with the VCC’s officer, manager and internal authority records so that an outdated title or former role does not quietly determine access.
Sources: ACRA · ACRA · MASCurrent-state evidence
- Full account list with the VCC and relevant sub-fund identifiers.
- Current mandate and every supplemental instruction accepted by the bank.
- Online user export showing creator, viewer, releaser and administrator rights.
- Tokens, mobile devices, authentication channels and registered contact details.
- Payment templates, beneficiaries, limits, dual-control groups and exception routes.
- Former staff, provider personnel, shared mailboxes and dormant users requiring confirmation.
Do not rely on a team member’s recollection or the visible user list alone. Some authority may sit in paper mandates, separate portals, host-to-host connections, administrator access, custody interfaces or alert settings. Record uncertainty as an open item and obtain confirmation before design approval. A clean target state built on an incomplete baseline can leave precisely the access the project was intended to remove.
Sources: MAS · ACRARelated guidance: VCC banking and custody onboarding checklist
Approve a target-state matrix
Design the future state by function rather than by copying a predecessor’s access. Separate payment creation from release, ordinary operations from exceptional transfers, and account visibility from authority to move funds. For an umbrella VCC, confirm the intended scope for each sub-fund account and any genuine platform-level account. The matrix should expose incompatible combinations and show how backup coverage works during absence.
Sources: MAS · ACRA| Role | Permitted activity | Prohibited combination | Backup design |
|---|---|---|---|
| Payment preparer | Create supported payments from approved instructions | Sole release of the same payment | Separate trained preparer with controlled access |
| Payment approver | Review evidence and release within assigned scope | Changing source documents after approval | Independent approver in the same authorised group |
| Read-only reviewer | Inspect balances, statements and workflow evidence | Creating beneficiaries or payments | Governance or finance backup with viewing access |
| Portal administrator | Maintain users under an approved instruction | Self-approving an expanded entitlement | Second-person review of every user change |
Approval path
- No legal-role changeApprove the bank and digital-access design under the VCC’s current internal authority and retain the basis.
- Officer or manager changeCoordinate registry, internal records, contracts and bank instructions without assuming that one update completes the others.
- Provider transitionDefine whether provider personnel need view, preparation or administrative rights and when each right ends.
- Unclear authorityPause the submission until the constitution, resolutions, agreements and professional advice support a coherent instruction.
Related guidance: family-office VCC access-rights matrix
Control the bank submission and cutover
Use one controlled submission pack with a document index, approved matrix, accepted bank forms, identity material supplied through the bank’s secure route and a named liaison. Track questions and resubmissions so that a correction does not become a second inconsistent instruction. Schedule the cutover around known capital activity and critical payments, and keep a clearly approved contingency for the period before replacement access is confirmed.
Sources: MAS · ACRACutover sequence
- Submission lockedConfirm that forms, identity records, account scope and entitlement matrix agree before the pack leaves controlled storage.
- Bank acceptance trackedRecord the bank reference, questions, amended documents and final accepted instruction as one audit trail.
- Replacement access testedVerify login, viewing, creation, release, limits, alerts and account scope with controlled low-risk tests.
- Former access disabledObtain direct evidence that users, devices, tokens and administrative rights marked for removal no longer work.
- Normal flow resumedRun an approved operational payment through the target workflow and reconcile every approval and notification.
Test every entitlement, not only login
A successful login proves very little. Test what each role can see, create, amend, approve and administer. Confirm account and sub-fund scope, beneficiary controls, approval combinations, limits, payment templates, alerts and statement access. Use a test script that records the expected result and actual result. Unexpected access is an incident for remediation; expected denial is useful evidence.
Sources: MAS · ACRAPost-change access test
- Each user sees only the approved accounts and sub-fund scope.
- Payment creation and release follow the approved separation of duties.
- Limits, beneficiary controls and exceptional-payment routes behave as designed.
- Alerts reach current controlled recipients and no former address remains active.
- Portal administrators cannot expand their own rights without an independent control.
- Removed users, tokens, devices and service-provider accounts fail controlled access attempts.
When a test fails, preserve the result, restrict the affected function if appropriate and agree the correction with the bank. Do not edit the approved matrix retrospectively to match the bank configuration. The matrix records the intended control; the portal and mandate must be brought to it or the governance owner must explicitly approve a revised design.
Sources: MAS · ACRARelated guidance: VCC cyber-incident provider response
Close the event across every record
The close pack should include the trigger, current-state inventory, approved target matrix, resolutions, submitted forms, bank acceptance, user exports, test results, removal evidence, open exceptions and final owner sign-off. If the event also changed a VCC officer, manager, registered information or internal register, reconcile the relevant ACRA and VCC records separately using the applicable official process.
Sources: ACRA · ACRA · MASClosure gate
- Bank confirmation and live entitlements match the approved target-state matrix.
- Former access and authentication tools have documented removal evidence.
- A normal controlled payment completed through the new workflow.
- Officer, manager and internal-record changes are reconciled where the event affected them.
- Temporary access and transition exceptions have expiry owners.
- Lessons and recurring access-review actions are entered into the governance calendar.
Repeat the entitlement review when a person changes role, a provider leaves, an account is added or an approval design changes. The mandate file should make the next review easier by preserving both the intended architecture and proof of the live result. That is the difference between a signed bank form and a controlled access migration.
Sources: ACRA · MASRelated guidance: VCC sub-fund counterparty pack
Frequently asked questions
Is a bank signatory always a VCC director?
Not necessarily. The relevant roles depend on the VCC’s governing records, internal approvals, bank terms and operating design. Map director status, contractual signatory authority and digital entitlements separately so that the team does not infer one capacity from another.
Should old and new users overlap during cutover?
Use only the controlled overlap or contingency supported by the approved plan and bank process. The aim is to avoid both orphaned former access and an operational dead zone. State who may act, for what purpose and how temporary access is closed.
What if the bank portal does not match the approved matrix?
Preserve the test result, restrict affected activity where appropriate and obtain a correction or an expressly approved design change. Do not treat the portal configuration as the authority merely because the bank system currently permits it.
How should sub-fund bank access be reviewed?
List every account under the relevant VCC and sub-fund identifier, then test user visibility and action rights against the approved scope. A platform role should not silently gain access to a sub-fund merely because several accounts share one banking relationship.
What proves that a former user has been removed?
Retain bank confirmation, a post-change user export and controlled evidence that the former credentials, device or token no longer provide access. An internal request email alone shows intention, not the live state of the bank system.
Official sources and further reading
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.