Insights / Private banking

AI in private banking in Monaco: preparing compliance, leaving the decision to people

By Basile Caillé, managing partner · 20 October 2026 · 12 min read

In a Monaco private bank, a considerable share of the work does not happen in front of the client but around their file: building the onboarding file, documenting the source of wealth, carrying out periodic reviews, preparing credit files. This is precisely where artificial intelligence brings the most, on one condition: it must be designed as a preparation tool, under the bank’s control, and never as a decision-maker.

This article looks at what AI prepares well in private banking compliance, what must remain a human decision, and how to frame a first project without exposing banking secrecy.

Why compliance is where the gain lies

In Monaco, the fight against money laundering, terrorist financing and corruption rests on law n°1.362 of 3 August 2009, strengthened several times since. It is supervised by the AMSF, the Monaco Financial Security Authority, created by law n°1.549 of 6 July 2023 to replace SICCFIN: an independent administrative authority that brings together financial intelligence, supervision and, now, the power to sanction. Licensing and prudential supervision of banks fall to the French ACPR under the Franco-Monegasque agreements, while portfolio management activities fall to the Commission de contrôle des activités financières.

Since the Principality was placed on the FATF grey list in June 2024, assessors have focused on effectiveness: proof, over time, that controls are actually applied, file after file. Whatever the outcome of the assessments, this requirement for proof remains, and it translates into hours: reading documents, cross-checking information, drafting summaries, keeping an audit trail.

The clientele of the Monaco financial centre adds its own complexity. Ownership structures that span several jurisdictions, documents in four or five languages, wealth built up over decades. Compliance work there is first and foremost reading and writing, which is exactly the kind of task a well-designed AI system speeds up.

Four tasks AI prepares well

The onboarding file

For a wealth management relationship, the file often brings together dozens of documents: articles of association, beneficial ownership registers, trust deeds, identity documents, proofs of address. AI reads them, extracts the useful information (companies, beneficial owners, ownership percentages, dates, jurisdictions), proposes an ownership chart, flags inconsistencies between documents and lists what is missing. The compliance officer starts from an already structured file instead of a pile of PDFs. We explain this mechanism, applied to multi-entity structures, in our analysis of family office onboarding.

The periodic review

Every relationship must be reviewed at a frequency that depends on its risk level. Most of the work consists of comparing the existing file with new information: documents that have expired, a change of shareholders, a change in activity, movements that are unusual for the profile. AI prepares this comparison, highlights what has changed and drafts a review note. For standard-risk relationships, which make up the bulk of the portfolio, this is often the largest source of time savings.

Source of funds and source of wealth

Documenting the origin of wealth means reconstructing a story: the sale of a business, an inheritance, a career, successive investments. AI can assemble this chronological account from the documents provided, linking every statement to its source (the document, the page, the passage). The result is not a conclusion; it is a verifiable working basis that the analyst completes, challenges or approves.

Credit file summaries

A Lombard loan or a property financing requires consolidating the client’s wealth, collateral, income streams and existing commitments. AI prepares a draft credit memo from the documents and internal data, in the bank’s format, with points of attention highlighted. The analyst saves the compilation time and focuses on assessing the risk.

In all four cases, the same principle applies: the tool prepares, flags and traces. Sorting screening alerts (namesakes, adverse media) follows the same logic: AI can group and summarise the results, explaining why an alert appears to be a false positive, but clearing the alert remains a decision documented by a person.

What stays human, and why that is a strength

Accepting a relationship, the final risk score, filing a suspicious activity report with the AMSF, granting credit: these decisions remain human. This is not a precaution of principle. The rules place responsibility for due diligence on the regulated institution, and that responsibility cannot be delegated to software.

It is also a very practical design criterion. On the day of an inspection, the question will be: why is this client rated medium risk, and on which documents does that assessment rest? The answer must be in the file, signed by a person, not in the inner workings of a model. A tool that links every element back to its source, keeps successive versions and logs who approved what strengthens this audit trail instead of weakening it.

Finally, this is where adoption is won. Compliance teams trust a tool that shows its sources and leaves them the final say; they work around one that asks them to take its word for it. We develop this point in our article on the difference between an AI agent and a chatbot.

Banking secrecy as a design constraint

In a private bank, the question is not whether AI can be used, but where the data goes. Three requirements shape the architecture:

  • Hosting: in Monaco, on a private European cloud or within the bank’s own infrastructure, with models deployed in that environment rather than called through a consumer service.
  • No training on your data: client information is never used to train a third-party model, and this is written into the contract.
  • Traceability: segregation by client, access rights aligned with those of the existing system, every consultation logged.

Three possible architectures

A model installed within the bank. The model runs on servers equipped with graphics processors, in the bank’s data centre or that of its usual hosting provider. No data leaves the existing perimeter, which simplifies the security review and the discussion with the group. Today’s open models (known as “open weight”, because their weights can be installed in-house) perform very well on the tasks described above: reading, extraction, classification, summarisation. The trade-off is an investment in hardware and a team, internal or external, to run and update it.

A private cloud, in Monaco or in Europe. The model is deployed on dedicated infrastructure, either with a sovereign cloud offering available in the Principality or on a private European cloud. Set-up is faster and capacity scales with volume. The choice of provider then matters as much as the location: a provider subject to extraterritorial legislation, such as the US CLOUD Act, does not offer the same guarantees as a European one, even when its servers are in Europe. The contract must set out the location, the ban on training and the reversibility terms in writing.

A hybrid architecture. Documents, the search index and the logs stay within the bank; only pseudonymised extracts, stripped of names and identifiers, are sent to a more powerful model hosted in a private cloud, for the rare tasks that justify it. This is often the best balance between performance and control, provided the pseudonymisation itself is carried out locally and checked.

Our recommendation for a first project

For private banking compliance, we recommend starting on premises or on a Monaco sovereign cloud, with a mid-sized open model: it covers most reading and summarisation needs, and it avoids opening a new flow of sensitive data before the gain has been measured. Two principles apply in every case. The document index and the logs stay within the bank’s perimeter. And the architecture is designed so that the model is interchangeable: models improve every six months, and the bank must be able to move to the next one without rebuilding the tool or depending on a single provider.

On data protection, law n°1.565 of 3 December 2024, overseen by the APDP, applies in full. Processing that analyses wealth management files at scale will in all likelihood call for an impact assessment and an update of the processing register; we set out the steps in our guide to law n°1.565. Many institutions in the Principality also belong to European or Swiss groups: the group’s AI policy and IT security should be involved from day one, which avoids designing a tool that nobody will be able to put into production.

One last practical remark. Consumer tools are tempting when the pile of files grows, and that is only human. The most effective answer is not one more prohibition, but an internal tool that is just as easy to use and makes the detour unnecessary.

Where to start

A successful first project comes down to three choices.

A single workflow, with measurable volume and gains. The periodic review of standard-risk relationships is often a good candidate: many files, a repetitive format, time spent that is easy to measure. Record the average time per file before starting: without a baseline, no gain can be demonstrated.

A prototype on real cases, in a controlled environment. Four weeks are enough to test the tool on a sample of files, within the chosen infrastructure, with two or three compliance officers as its first users and first critics. Our article from POC to production explains what takes this prototype to scale.

Indicators tracked over time. Time per file, share of missing documents detected at the preparation stage, feedback from internal control. These figures are what justify extending the approach to other workflows.

Before choosing a provider, seven questions help sort the options:

  • Where are the data and the models hosted, and who can access them?
  • Can the model be replaced by another without rebuilding the tool?
  • Is the bank’s data used, directly or indirectly, to train a model?
  • Can every element produced by the tool be traced back to its source?
  • Who approves, and how is that approval recorded?
  • How does the tool fit with existing access rights and logs?
  • What happens at the end of the contract: does the bank keep the tool, the data and the documentation?

AI will not make compliance any less demanding. Well designed, it gives compliance time back: the time teams spend compiling today, which they can devote to analysis, judgement and the client relationship. We detail the tasks involved and the applicable framework on our page AI for private banking in Monaco.

Contact

From readingto action.

A 30-minute conversation to identify a first high-impact use case in your organisation.

Book a meeting