ChatGPT
Claude
Google AI
Copilot
The platform does not change when the customer is a bank, an insurer or a wealth manager. The delivery does, and teams coming from commercial mid-market work are usually surprised by the same four things.
None of them are insurmountable. All of them are much cheaper to plan for than to discover.
1. The modelling problem is relationships, not accounts
In most B2B implementations the account model is straightforward: a company, some contacts, maybe a parent-child hierarchy.
In financial services the interesting entity is rarely a single party. It is a household with two adults and a trust, an SMSF with corporate trustee, a business owner who is also a retail customer and a guarantor on a third party's loan. The same human appears in several roles across several groupings, and the roles carry different rights.
This is what Financial Services Cloud's group and relationship modelling exists for, and it is why a generic Account-and-Contact design fails here, not because it cannot store the data, but because it cannot answer the questions.
The questions that drive the design:
- Which groupings does the business actually service and report on? Household, entity group, adviser book?
- For any given person, what should an adviser see, and what must they not see, when that person appears in someone else's group?
- Which relationships are commercially meaningful versus merely informative?
Get those answered in workshops before choosing objects. The tooling follows the answers.
2. Auditability is a design input
In commercial work, "who changed this and when" is a nice-to-have that gets added if someone asks. In regulated work it is a requirement, it is asked about in audits, and it has to be true retrospectively.
That has practical build implications from day one:
- Field history has a limited number of tracked fields per object and only starts recording once enabled. Turning it on later does not backfill. Decide the tracked list during design.
- Extended retention matters, because standard history retention is often shorter than the retention period the regulator expects. Know your obligation and match it, whether through Field Audit Trail or an archive.
- Access logging, who viewed a record, not just who changed it, is a separate capability with its own cost, and it is frequently a hard requirement for customer data.
- Consent and communication preferences need a defensible record of what the customer agreed to, when, and through which channel.
3. The sharing model carries regulatory weight
In a commercial org, over-sharing is untidy. In a regulated one it is a finding.
Expect specific constraints that shape the design:
- Advisers see their book, not the firm's book. Team access is by exception and usually time-bound.
- Some data is restricted by role rather than ownership, complaints, vulnerable customer flags, matters under investigation.
- There may be genuine information barriers between business lines, where two teams inside the same firm must not see each other's clients.
Those requirements interact badly with a role hierarchy that models the org chart. Design the hierarchy around data access, and use it deliberately. Where restriction rules cannot be expressed through ownership and hierarchy, you will need restriction rules, scoping rules or separate objects, and it is much better to know that in design than to discover it in UAT.
4. Release cadence belongs to change governance
The delivery team does not set the release calendar. Change governance does, and in a regulated environment that typically means:
- A change advisory board with a fixed meeting schedule.
- Documented testing evidence, signed off, before approval.
- Defined freeze windows, end of financial year, reporting periods, regulatory submission dates.
- A written, tested rollback plan for anything touching customer data or customer-facing process.
Plan around this rather than against it. Practically: batch changes into predictable releases, keep the evidence pack as a build artefact rather than a scramble the week before, and get the freeze calendar in week one so the plan is honest.
The things that add weeks before build starts
Two more, less discussed, that consistently affect timelines.
Vendor and platform review. Any new tool, package or integration endpoint may require security review, and the queue is not controlled by your project. Submit early. This includes AppExchange packages that seem uncontroversial.
Data residency and third-party processing. Where data is stored and processed is a contractual question with a specific answer, and it constrains architecture, which environments, which regions, which services can be used, and what can leave the tenancy. This is now a routine early question for any AI capability in particular, and it deserves a straight answer before a design depends on it.
What good delivery looks like here
The pattern that works is not slower delivery. It is front-loaded decision-making: more design, earlier compliance involvement, and evidence produced continuously rather than assembled at the end.
Teams that treat compliance as a gate at the end deliver twice, once for the business, then again for the reviewer. Teams that bring risk and compliance into design workshops deliver once, and the review is a confirmation rather than a discovery.
More on how we work in this sector: Salesforce for financial services.
