Bring Your Own Front End: Vibe-Code (AI) the Portal, Not the Controls

What if advisors could design their own client portals without waiting for a vendor's development backlog?

Not another standard dashboard..

Their own experience:

• A liquidity view for the family-office principal.
• A meeting-preparation workspace for the advisor.
• A restricted document view for a beneficiary.
• An exceptions dashboard for operations.

AI coding tools make that increasingly accessible.

But there is a catch:

The freedom to build a screen should not include the freedom to rewrite the financial infrastructure underneath it.

Vibe coding (AI) is attractive. Production is different.

"Vibe coding" means describing what you want to an AI coding assistant and iterating on the software it produces.

It can make experimentation easier.

It does not establish that the result is secure, accurate or ready for clients.

Four things can go wrong behind an impressive interface:

• The tool changes core data to make a screen work.
• Permissions hide information visually but do not prevent access.
• Different dashboards calculate the same number differently.
• Stale data appears current because the page loaded successfully.

A polished portal can conceal an uncontrolled process.

Separate the experience from the authority

"Bring your own front end" should mean the firm controls the look and feel—not that every new interface invents its own rules.

The architecture should separate:

• Front end: layouts, navigation and visualisations.
• Unified Data Model: consistent definitions of households, entities, ownership and valuations.
• Data Orchestration Layer: controlled movement of data and workflows between systems.
• AI Harness: the software surrounding the model that manages context, tools, permissions and execution.

Put simply:

Customise the experience. Centralise the rules. Retain ownership.

The firm can own its portal code in a private GitHub repository (a GitHub repository is an online workspace that stores a project's code, files and history of changes. Think of it as a shared project folder with version tracking, so authorised people can collaborate, review edits and recover earlier versions. It can be private, limiting access to approved users.) and its information in a client-owned database, while governed services enforce how that information is accessed and used.

Permissions belong behind the screen

Hiding a button is not security.

A family member's dashboard should reflect what that person is authorised to see—not merely what the interface chooses to display.

Access needs to account for:

• Role.
• Household.
• Legal entity.
• Account.
• Document.
• Delegated authority.

Those permissions must be enforced by the underlying system, including for direct requests, downloads and exports.

My favourite test:

"Show me that the request fails—not just that the button disappears."

Let AI configure. Let approved code calculate.

An AI toolkit can help an advisor design an analysis, configure a workflow or create a new visualisation.

But an established exposure calculation should not be reinterpreted by a model every morning.

"Calculations as code" means recurring methods run as tested, version-controlled software.

Keep a record of:

• Inputs and valuation dates.
• Ownership and currency rules.
• Calculation versions.
• Expected test results.
• Approved changes.

Code still needs validation. The point is reproducibility—not pretending code cannot be wrong.

An MCP connection is not a control framework

An MCP server connects AI applications to tools and data through the Model Context Protocol.

Useful? Yes.

A safety certificate? No.

Official MCP guidance documents risks including token misuse and services being tricked into exercising authority for the wrong party. OWASP also identifies prompt injection, sensitive-information disclosure and excessive agency as major risks in LLM applications.

Guardrails need to be enforceable:

• Narrow permissions.
• Separate read and write access.
• Approval for sensitive actions.
• Validated inputs and outputs.
• Accessible audit logs.

Prompts are instructions. Controls must still work when instructions fail.

Before go-live, test what should not happen

The most important demonstration is not that the portal works.

It is that the boundaries work.

Before release:

• Try accessing another household's data.
• Reconcile balances and record counts against source systems.
• Run calculation regression tests—checks that changes have not broken approved results.
• Simulate missing feeds and stale valuations.
• Review generated code and scan for exposed credentials.
• Test deployment, recovery and rollback.

Auto-deploy should mean approved changes pass automated checks before release—not that every conversational edit reaches clients.

And changing a shared definition, such as "household liquidity," needs more scrutiny than changing a chart colour.

NIST's voluntary AI Risk Management Framework supports this emphasis on testing, measurement and ongoing monitoring; it is not a compliance certification.

Ownership without portability is incomplete

A client-owned database and repository are a start.

Real independence also requires:

• Documented data definitions.
• Portable calculation and workflow logic.
• Clear rights to the code.
• Accessible audit records.
• Named maintenance responsibility.
• A workable handover plan.

Otherwise, vendor lock-in has simply moved from the dashboard to the infrastructure.

Be equally honest about source limitations. If a field is unavailable in bulk, needs a second source or is out of date, say so.

"Unavailable" is not the same as zero.

Five questions buyers should ask

1. Can an unauthorised user retrieve data outside the interface?
2. Can you reproduce a reported figure from its inputs and calculation version?
3. What tests must pass before code or data-model changes reach production?
4. How do users know information is missing, stale or unreconciled?
5. What can we continue operating if we change providers?

The regulatory backdrop reinforces the need for discipline: the SEC's amended Regulation SP safeguards requirements have reached their compliance dates for covered institutions. Using AI does not remove those obligations.

The opportunity is not to turn every advisor into a software engineer.

It is to give advisors creative freedom without giving every interface operational authority.

Build the experience you want.

Keep the data, calculations and permissions behind a boundary you can test.

Sources

1. GitHub Repositories Documentation
2. MCP Security Best Practices
3. NIST AI Risk Management Framework
4. SEC Regulation S-P Compliance Guide