The starting point
The client is a UAE bank with a meaningful corporate banking book, a growing wealth-management arm, and a Salesforce Financial Services Cloud deployment that had been running for four years. The deployment covered the relationship-banking workflow, the customer-onboarding journey, the cross-sell motion across the personal and business sides of the book, and the financial-account modelling that the wealth team had built against the FSC data model. The licence cost was material. The renewal sitting on the chief operating officer's desk in mid-2026 was the third successive increase.
The brief from the chief technology officer was specific. He did not want to argue with the Salesforce account team about the discount. He wanted to know what the bank's operating cost looked like if FSC were no longer load-bearing for the relationship and onboarding workflows. The wealth-management modelling could stay on FSC for the time being. The two largest licence consumers — the relationship managers and the onboarding team — were the candidates for the work.
Sixteen weeks from kickoff. This is what they contained.
Weeks 1 to 3 — the map
The first three weeks were not building. They were mapping. The FSC instance had four years of integrator-led customisation stacked on top of it. The relationship-banking workflow alone touched eight custom objects, twelve flows, and a permission model that the integrator had refined repeatedly. The onboarding journey was a hybrid of FSC native and a custom-built journey that the bank's digital team had bolted on in year two.
Mapping had three outputs:
A workflow-level inventory of which FSC features were load-bearing for the business and which were artefacts of past integrator work that the business had stopped using. About 40% of the configuration in the relationship-banking workflow had no active use. Nobody was sad to learn this.
A data-contract specification for the boundary between the replacement system and the systems that would continue to consume FSC data during the parallel-run period. The wealth-management modelling stays on FSC for the duration; that team needed the relationship data in the same shape it received it today. The bank's data warehouse needed the customer interaction data in the same shape it received it for compliance and regulatory reporting.
A risk register that the bank's risk and compliance functions signed off on before any build began. Onboarding workflows in a UAE bank touch regulator-sensitive controls. None of those controls were going to operate in a less rigorous way after the replacement than before it. The risk register was the artefact the chief risk officer needed to authorise the work.
Weeks 4 to 9 — relationship banking
The relationship-banking workflow was built in six weeks. The components:
A relationship-manager workspace built as a web application against the bank's owned identity and access management. The workspace consolidated the views the relationship managers had been opening in three separate FSC tabs into a single working surface, with the activity history, the customer financial position, the pipeline of opportunities, and the team-assignment surface all visible in one place.
A relationship-data model that lived in the bank's own data layer, organised against the bank's customer-relationship taxonomy rather than the FSC standard taxonomy. The bank's relationship hierarchy — household, business, group, ultimate beneficial owner — had been forced into the FSC data model imperfectly for four years. The replacement modelled it cleanly.
An activity-capture surface that captured the relationship manager's interactions with the customer, the call summaries, the meeting notes, and the action items. The activity surface incorporated an assistive agent that drafted call summaries and next-action recommendations from the manager's voice notes. The manager retained the final decision on every action.
A boundary back to FSC during the parallel-run period that pushed the activity data into FSC's objects in the same shape FSC continued to read them. The wealth-management modelling did not see a change. The downstream reporting did not see a change.
The pilot user cohort — twelve relationship managers across two coverage teams — went live at the end of week 9. The relationship-manager population began rolling onto the new workspace over the following four weeks.
Weeks 10 to 14 — customer onboarding
The onboarding journey was the higher-risk surface. It touches the bank's KYC controls, the AML screening, the regulatory-disclosure delivery, and the integration into the core's customer-master. The replacement was scoped accordingly.
The new onboarding surface ran the same control sequence the FSC version did. The KYC capture, the document validation, the screening against the sanction lists, the customer-risk scoring, the regulatory disclosure presentation and acknowledgement, the new-customer record creation. Each step was identical in its compliance posture. Each step was logged in the same audit format the bank's internal audit team had been working with.
What changed was the customer experience and the colleague experience. The customer-facing journey ran as a guided flow against the bank's mobile-first onboarding surface, with the document capture, the liveness check, and the disclosure flow consolidated into a single coherent sequence. The colleague-facing review surface presented the case in a working form the relationship and onboarding teams could act on. An assistive agent summarised the case, flagged the non-standard elements, and prepared the recommendation. The reviewer retained the decision.
The pilot cohort for onboarding was a single branch network and the digital onboarding channel. Go-live was end of week 14.
Weeks 15 to 16 — data residency and handover
The CBUAE has formalised the sovereign financial cloud direction over the last 18 months. Banks operating in the UAE now have a clear path to running sensitive workloads on infrastructure that satisfies the regulator's data-residency expectations. The replacement we built was scoped against that direction from week one. The data layer, the application layer, and the AI inference for the assistive agent all run on infrastructure the bank had already approved with its regulatory team.
The last two weeks of the engagement were handover. The bank's platform engineering team, the operations team for the relationship-banking workspace, and the operations team for the onboarding surface took ownership of the running systems. The runbook, the eval suite for the assistive agent, the prompt versioning, the observability surface, and the on-call rotation moved to the bank. The saasinator team rolled off.
What happened with the FSC contract
The Salesforce account team learned about the work at the end of week 9. The conversation that followed was the conversation the chief technology officer had been hoping for. The remaining FSC footprint at the bank — the wealth-management modelling, a handful of dashboards, and the residual reporting — sat on a footprint roughly a third of what it had been at the start of the year. The renewal that landed in the new year reflected the smaller surface area. The discount conversation became substantive, not theatrical.
The saasinator perspective
The Middle East banking market is in a different posture now than it was three years ago. The regulator's direction on sovereign cloud is clear. The market expectation on AI-native banking is clear. The integrator ecosystem is responsive when banks demonstrate they have alternatives. The bank that runs the work above is in a materially stronger position on every commercial conversation about its technology portfolio.
The work is not theoretical. The engagement above is real, anonymised here, and the architecture moves cleanly to the next Middle East bank that wants to run a similar sequence. The 16-week envelope is achievable for a bank of comparable scale and comparable starting posture. The decision to run it is a board-level conversation about which workflow flips first, not a multi-year programme funded once.
What to bring to the diagnostic
If your bank is operating Salesforce Financial Services Cloud across the relationship and onboarding workflows and the 2026 or 2027 renewal is being prepared, the conversation worth having is which workflow you would test against in a four-week pilot. Bring the FSC licence schedule, the integrator retainer for the FSC estate, the data-residency posture you have agreed with the regulator, and a list of the load-bearing workflows you would not want to disturb.
Book a diagnostic. Fifteen working days for a regulated institution. Output is the workflow recommendation, the architecture sketch, and the first-quarter scope.