How can a bank innovation team run a design pilot that survives compliance review?
A bank innovation team can run its first paid design pilot through vendor-risk and compliance review with an eight-week plan, a data rule and a legacy constraint map.
Picture an innovation team that has chosen a design agency and signed a pilot letter. In week three, information security asks where the agency keeps its Figma files. Legal asks whether the designers may see real account screens. The core banking team explains that the status the prototype promises does not exist yet. Each question is ordinary, and each costs weeks when it arrives late. This scenario is illustrative.
This guide starts after the shortlist. If you still need one, our comparison of design agencies used to bank compliance and legacy systems comes first. Humbleteam, a product design agency, publishes this guide. It uses the UAE as its worked example because the Central Bank of the UAE (CBUAE) publishes its rules in an open rulebook. It is not legal advice. Your bank’s compliance team decides which rules apply to your pilot.
Is a design pilot “outsourcing”? Ask before anything else
CBUAE’s Outsourcing Regulation for Banks defines outsourcing as an agreement for another party to perform, on a continuing basis, an activity the bank could do itself (Article 1.10). The bank must judge how material each outsourced activity is. A material one needs the central bank’s non-objection before the agreement is signed (Article 8.1). Every arrangement, material or not, goes into a register that records whether it involves confidential customer data (Article 3).
A short design pilot might fall outside that definition, or inside it as a non-material arrangement. Only the bank can say which, and it should say so in writing before week 1, because the answer sets the paperwork. If the pilot is material, the non-objection comes first and your eight weeks begin afterward.
Other regimes sequence the work the same way. The EBA outsourcing guidelines place risk assessment and due diligence before any arrangement starts. The 2023 US interagency guidance lists planning and due diligence ahead of contract negotiation.
The Outsourcing Regulation binds the bank and reaches the agency only through the contract. Consumer data sits under several regimes, and each covers different people. CBUAE’s Consumer Protection Regulation covers customers who are individuals and sole proprietorships, and a separate SME regulation took effect on September 13, 2026. The federal Personal Data Protection Law excludes personal banking and credit data that has its own legislation, and free-zone companies with their own data laws. So ask for an answer per data type.
What should the agency provide before week 1?
CBUAE’s Outsourcing Standards list what a bank’s due diligence on a provider covers: financial capacity, relevant experience, governance and internal controls, security including cyber security, staffing, and country and legal risk. Turn that list into a request, and ask for the answers before the pilot letter is signed:
- Legal entity, ownership and proof the agency can finish eight weeks of work.
- Two comparable references from regulated clients, with a contact who can describe their review cycles.
- A security summary: where files and recordings are stored, who can open them, and how access ends.
- A tool register: every tool the team will use on bank material, AI tools included, with hosting country and whether uploads train a model. This item is our suggestion, not a regulatory requirement.
- Subcontractors and freelancers, with the country each works from. The regulation expects the contract to say how far subcontracting is allowed (Article 5.6).
- The named team, and a rule that replacing anyone needs the bank’s approval.
- A continuity plan: what happens if the lead designer leaves or a tool goes offline.
- Willingness to accept the contract terms the regulation lists for outsourcing: the bank owns the data, an NDA applies, data is destroyed afterward, and breaches are reported without undue delay (Article 5). Whether they apply is the bank’s call.
What data can the agency touch?
Start from a default of no customer data in design tools. The Outsourcing Regulation defines confidential data as account or other data about a customer who can be identified from it, alone or together with other information (Article 1.6). A masked export therefore still counts if someone can link it back to a person. Banks must not share that data outside the UAE without central bank approval and the customer’s prior written consent (Article 6.3), and must protect it from unauthorized access, including by the provider’s staff (Article 4.4).
A pilot does not need any of it:
- Build prototypes on synthetic accounts with invented names and balances. The bank’s data team checks that formats and field lengths match reality.
- Capture real screens from a test environment, never production. No production screenshot goes into a design file or an AI chat.
- Research with customers runs through the bank. It recruits, collects consent and stores recordings under its own policy. CBUAE’s consumer standards require explicit consent in plain language and a right to withdraw it (6.1.3).
- At the end, the bank should be able to show that files were returned or destroyed, as the same standards require when an outsourcing contract ends (6.1.4.5).
The 8-week pilot plan, with a gate in each phase
Compliance, legal and risk join at set points, each with a named reviewer and a written outcome. They do not arrive in week 8 with a list of objections. This is a planning model, not a Humbleteam standard or a promise. Real timing depends on your bank’s review queues.
| Week | Phase | Work | Gate before the next phase | Record kept |
|---|---|---|---|---|
| Before 1 | Vendor onboarding | Bank classifies the arrangement, reviews the agency pack, signs contract and NDA, approves the tool register | Risk and procurement approve; data protection function signs the data rule | Classification note, register entry |
| 1 | Frame the journey | Pick one journey, its start and end states, and what is out of scope | Compliance and legal confirm which rules touch this journey | Scope sheet, reviewer list |
| 2 | Map constraints | Walk the journey with product, operations and the owners of core and integration systems | Each line of the constraint map is confirmed by a named owner | Constraint map v1 |
| 3 | Concepts | Two or three options on synthetic data, including pending and failed states | Compliance reads disclosures, consent and wording before any testing | Review log |
| 4 | Prototype | Clickable prototype with draft content in every state and language | Legal approves wording; security approves where the prototype is hosted | Wording approvals |
| 5 | Test | Sessions with bank-recruited participants; engineers check each state against a supported system response | Consent and recordings follow bank policy; each state is marked feasible, changeable or blocked | Findings, feasibility marks |
| 6 | Revise | Fix what testing found and retest the changed states | Second compliance review of every changed disclosure, consent or status screen | Updated decision record |
| 7 | Specify | Write states, content, rules, acceptance checks and a screen-to-requirement trace | Risk reviews the open-risk list | Specification, risk list |
| 8 | Hand over | Review with sponsor, compliance, risk and engineering; return or delete files | Sign-off of the decision record; deletion confirmed; register updated | Handover pack |
A one-page legacy constraint map
Most pilot surprises are facts nobody wrote down: what the core system can return, how quickly, and what it cannot store. Copy the table below into a single page and fill it in during week 2. A line with no named confirmer stays marked “unconfirmed”, and no design may depend on it. The rows are invented examples.
| Step or state | Data it needs | System of record | Can and cannot do | Confirmed by and date | Design consequence |
|---|---|---|---|---|---|
| Card replacement status | Request state | Card management system | Exposes “ordered” and “dispatched” only, with no tracking | [Card systems owner, date] | App shows those two real states and no delivery estimate |
| Fee disclosure before payee confirmation | Approved fee text | Compliance content library | Text and position fixed by compliance | [Compliance lead, date] | Fee line stays above the confirm button in both languages |
| Payee name entry | Name as typed | Payments engine | Field holds 35 characters and cuts longer names | [Payments integration owner, date] | Form warns before the limit; long names go on the open-risk list |
What the pilot should hand over
- A validated journey: the flow, every state including pending and failed ones, and what testing showed.
- A build-ready specification for the bank’s engineers: states, content in each language, rules, acceptance checks, and each screen traced to a supported system response.
- A record of compliance decisions: each requirement, who decided, when, and which screen it shaped.
- An open-risk list: each item with an owner, a date and a note on whether it blocks release.
Where this plan breaks
Approval time can break the schedule. If a non-objection or a security review runs long, move the dates and keep the gates. Synthetic data hides awkward real cases such as long names and unusual characters, so ask the bank’s team to add known ones. A constraint map goes stale, so the core system owner should reconfirm it before build. One piloted journey shows how a team works with your reviewers. It does not prove the design suits every product, and it does not replace the bank’s own release process. Rules also change: CBUAE’s SME customer regulation took effect only in September 2026.
Before any contract, you can write three documents: the classification question for compliance, the agency pack request, and a first draft of the constraint map for your chosen journey.
