Most client portals in private wealth are built as vaults. Documents go in, clients log in, files come out. The security may be sound. The experience still sends the client back to email for every question that matters: what does this figure include, which statement replaced which, who else in the family can see this, and why does this number differ from last quarter’s. A portal that answers those questions itself reduces email traffic, and email is where sensitive files most often go astray.

This note reflects texts and guidance available on 25 August 2026.

The portal is also a rights channel

Monaco’s data protection texts already expect something close to a portal. Article 12 of Law No. 1.565 gives each person the right to obtain, within one month, confirmation of whether their data is processed, the purposes, the recipients, the envisaged retention period or its criteria, and a copy of the data. Where the request is made electronically, the answer is given in a commonly used electronic form unless the person asks otherwise.

Sovereign Ordinance No. 11.327 goes further. Its first article states that, where possible, the controller should be able to give remote access to a secure system through which the person can reach their own data directly. It also requires information sent electronically to travel securely, in line with the sensitivity of the data.

A portal built with this in mind can answer much of an access request by design: a page that lists what the firm holds about the person, why, for how long and who receives it. The legal answer and the client experience become the same screen.

Delegates, handled like mandates

Private capital portals rarely serve one person. A principal adds a spouse, an adult child, a lawyer, an accountant. Portals often handle this with shared logins or a single “full access” switch. Both erase the record of who did what.

The ordinance offers a better model. For a rights request made through a representative, article 1 requires the representative to prove their identity and the principal’s, and to hold a mandate stating its duration and its precise object. The mandate must also say whether the representative may receive the controller’s reply.

A portal can mirror that structure for everyday access:

  • each delegate has their own login, never a shared one;
  • each delegation names its scope: which entities, which document types, read or download;
  • each delegation carries an end date and expires on its own;
  • the principal can see, at any time, the list of delegates and what each one opened.

The principal’s list of delegates then reads like a set of mandates, which is what it is.

Explain each figure

Explanation is a design feature, not a help page. Four habits carry most of the weight:

  • Date every figure. A valuation shows the date it refers to and the date it was published. “As of 30 June, published 14 August” prevents half the questions a quarter.
  • Name the source. Each position links to the statement or report it came from, so a client can trace a number to a document.
  • Show supersession. When a corrected statement replaces an earlier one, the earlier one stays visible, marked as replaced, with the reason. Silent replacement breeds doubt.
  • Explain the structure once. A diagram of the holding structure, kept current, tells a family member which entity a document belongs to before they open it.

Notifications follow the same rule in reverse. The email says that a new document is available. It does not carry the document, its figures or the entity’s name in the subject line.

The security line

Explanation must not weaken protection. The authentication question comes first. NIST’s SP 800-63B-4, published in July 2025, states that verifiers at its second assurance level shall offer at least one phishing-resistant authentication option, and that one-time codes and out-of-band authenticators are not phishing-resistant. Passkeys or hardware security keys suit principals and anyone who can approve instructions.

Sessions need limits. At the second level, the same guidance says the overall reauthentication timeout should be no more than 24 hours and the inactivity timeout no more than one hour. At the third level, the overall limit is 12 hours and the inactivity timeout should be no more than 15 minutes. A portal can apply the stricter settings to actions such as adding a delegate or changing contact details.

Authorisation is where portals most often fail. OWASP’s Authorization Cheat Sheet asks for least privilege, deny by default and a permission check on every request. Its guidance on insecure direct object references describes the classic break: a user changes a document number in a link and receives another client’s file. Hard-to-guess identifiers help, but only an access check on each object stops it. Every download link in a private capital portal should pass that test.

Monaco also has its own framework for strong identity. Law No. 1.483 on digital identity defines low, substantial and high levels of assurance and allows private-sector bodies to issue digital identities. The ordinance permits digital identity data to be used to verify a person making a rights request, where the controller judges it necessary and sufficient. Whether a portal accepts such identities is a product decision. The levels give the firm a vocabulary for it.

Where the portal lives

A portal holds the firm’s most sensitive documents in their most accessible form. It belongs on infrastructure whose transfers the firm has analysed, operated by people whose access is logged, and separate from the public website. Hosting it in Monaco or on the firm’s own servers shortens the list of processors and jurisdictions involved. It does not replace the controls above.

Questions to put to a portal design

  • Can a client see, on one page, what the firm holds about them and why?
  • Can a delegate’s access be limited by entity, document type and date?
  • Does each figure show its reference date, publication date and source?
  • Does a changed identifier in a link ever return someone else’s document?
  • Can the firm say, from its logs, who opened a given file and when?

Limits of this note

This is not legal advice. It reflects Monegasque texts and published guidance available on 25 August 2026. Firms supervised by the CCAF or other authorities should confirm what their own rules add on client reporting. To discuss a portal design, write to contact@desgarde.com.

Sources & further reading.

Original materials behind this perspective. Source pages may have changed since the period covered.

  1. Authorization Cheat Sheet ↗OWASP · Accessed 22 September 2026

Bring it into your own context.

Your firm’s information, obligations and operating constraints shape the right approach.

contact@desgarde.com