The most important decision in an AI financial product may be what the model is physically unable to do.
It is easy to describe safety as a prompt:
Do not perform a financial action without the user's permission.
That sentence is useful guidance. It is not an access-control system.
If the same process can read private financial data, construct a provider request, and call the endpoint that moves money, then the real boundary is model behaviour. A prompt injection, tool-selection error, stale context, confused identity, or ordinary application bug can cross it.
I prefer a stricter design: the intelligence system remains advisory. It can analyse evidence and prepare a decision, but it has no provider credentials and no write path into the money system.
Advisory is an architectural property
Calling a feature "advisory" does not make it advisory. I look for properties that can be verified:
- No payment-provider credentials exist in the intelligence service.
- No route can debit a wallet, lock funds, create a transfer, or settle a transaction.
- Execution-looking requests produce blocked audit records rather than financial side effects.
- Predictions and readiness results are labelled as projections, not balances or reservations.
- The service can read only the minimum facts required for the approved purpose.
- Revoked consent prevents another refresh of protected data.
These constraints remain true even if the model emits the worst possible output. That is the standard I want from the boundary.
Separate evidence from language
Large language models are good at turning structured evidence into understandable explanations. They are also capable of sounding certain when the evidence is incomplete.
The safer pattern is to compute important facts outside the model.
textauthorised data sources -> normalised facts -> deterministic calculations and policy checks -> evidence bundle with freshness and limitations -> model explanation -> advisory response
The model can explain why a forecast changed. It should not invent the balance observations, silently redistribute missing inputs, or decide that stale data is current enough.
Every material claim should be traceable to a fact, calculation, or explicitly identified assumption. When the required evidence is missing, the correct output is unavailable or setup required, not a confident guess.
The mobile application is not a trusted gateway
A mobile client is controlled by the person holding the device. Its traffic can be inspected, modified, and replayed. Shipping a server credential inside it turns that credential into a public secret with extra steps.
The path should look like this:
textmobile application -> authenticated product backend -> server-to-server intelligence service -> minimised advisory response
The product backend owns the user session and authorisation decision. It supplies a bounded server-to-server identity context. The intelligence service derives its internal subject identity without copying an entire customer profile.
On logout or account switch, locally cached advisory state must be cleared. Otherwise a correct server boundary can still be undermined by stale client state.
Consent belongs before the cache
Caching creates a subtle failure mode.
Imagine a user grants access, receives an analysis, and later revokes consent. If the application checks the cache before checking current consent, it may continue returning an old protected result.
The order matters:
textauthenticate -> authorise subject and account context -> verify current consent -> evaluate cache eligibility and freshness -> read or recompute
A cached response is still a disclosure. Consent cannot be treated as a one-time condition that permanently blesses the data.
Drafts are safer than actions
Some financial workflows benefit from AI preparation. A model can draft a plan, identify missing information, or suggest how a user might adjust a target.
The output should enter the product as a draft with visible provenance and editable fields. A separate deterministic workflow can validate and activate it after the user confirms the decision.
This gives us a useful state transition:
textAI suggestion -> DRAFT -> user review -> validated activation
It avoids the much more dangerous transition:
textAI suggestion -> provider side effect
Human review is not decorative here. The system should preserve what was suggested, what the user changed, what rules were applied, and which final action was authorised.
Execution should be another system's responsibility
Eventually, the user may want to act on the advice. The execution system should re-authenticate, re-authorise, validate current state, apply transaction controls, and obtain whatever approval the action requires.
It should not trust an advisory response as an instruction merely because both systems belong to the same product.
The advisory system says, "Based on these current facts, this option appears feasible."
The execution system asks, "Is this user authorised, is the state still current, are the funds available, and may this exact action proceed now?"
Those are different questions and deserve different trust boundaries.
The boundary makes the product easier to reason about
Keeping AI outside money movement is sometimes described as a limitation. I think it is a source of clarity.
The intelligence service can optimise for evidence, explanation, scenarios, and uncertainty. The execution service can optimise for authorisation, atomicity, limits, settlement, and auditability. Each system has a smaller responsibility and a failure mode that is easier to contain.
A prompt can still remind the model to behave carefully. The architecture should make sure the money does not depend on whether it listened.