1. Background & Objectives

1.1 Background

All IBAN-based payment flows within the PayBy wallet ecosystem currently rely on IBANs issued by FAB (First Abu Dhabi Bank). To reduce single-bank dependency risk, optimize cost structure, and improve system flexibility, a full migration of all IBAN payment flows from FAB to Zand Bank is required.

This migration spans 5 core use cases, impacting approximately 212K+ active users/corporates, with a monthly transaction volume of ~10-15M AED.

1.2 Objectives

• 100% of active FAB IBAN users migrated to new IBANs (Zand / PayBy / ENBD)
• 100% of new users onboarded directly with new IBANs
• Full decommissioning of FAB IBANs with zero residual dependencies
• Zero fund loss and zero business disruption throughout the migration

1.3 Migration Scope Overview

2. Overall Migration Architecture

2.1 Migration Timeline (Master View)

2.2 Migration Phasing

2.3 Dual-IBAN Parallel Architecture During Migration

Key Design Decision: During the overlap period, both old and new IBANs can accept funds. Any funds received via FAB IBANs are manually transferred to the Zand Escrow account by the C&S team, ensuring unified fund reconciliation.

3. Detailed Use Case Migration Plans

3.1 Use Case 1: Lean Wallet Top-up (P0)

Target: 8.2K users → ENBD IBANs
Notification: Yes - App UI
New Users: Mid-Feb 2026 | Existing Migration: W2-Apr → W4-Apr

3.1.1 New User Flow (Mid-Feb)

3.1.2 Existing User Migration Strategy (W2-Apr → W4-Apr)

Key Decisions:

• Active user definition: Unique member_IDs with ≥1 Lean transaction in the last 6 months (Aug 2025 – Jan 2026)
• Lean new users go live earliest (Mid-Feb), but existing migration is deliberately scheduled last (W2-Apr) to allow the GP flow to stabilize
• Inactive users have their destination delinked immediately; they enter the new GP flow on next usage

3.2 Use Case 2: IBAN Wallet Top-up (P1)

Target: 19.8K users → Zand IBANs
Notification: Yes - App UI
New Users: W1-Mar 2026 | Existing Migration: W2-Mar → W1-Apr

Prerequisite: Zand IBAN fund-in Pilot testing passed (end of Feb 2026)

3.2.1 New User Flow (W1-Mar)

Note: KYC team must be updated — new users post-KYC will receive Zand IBANs instead of FAB IBANs.

3.2.2 Existing User Migration (W2-Mar → W1-Apr)

Migration Timeline:

Risks & Mitigations:

• Users on old App versions: Some users may not receive In-App notifications → send SMS/Push notifications in parallel
• Checkout UI requirement: Existing user migration requires UI on checkout page to display new IBAN — coordinate with frontend team

3.3 Use Case 3: AANI Activation & Transactions (P1)

Target: 134.6K users → PayBy IBANs (413 bank code)
Notification: Not required (backend-only change)
New Users: W1-Mar 2026 | Existing Migration: W2-Mar → W2-Apr

Overview

In the AANI flow, IBANs are configured at the backend during user enrollment. Users are never exposed to the IBAN — no user-facing communication is required.

Per the team's recommendation, AANI will adopt PayBy's own 413 IBAN (PayBy bank code) rather than Zand IBANs. As a CBUAE-licensed SVF & RPSC, PayBy is eligible to use its own bank code.

Migration Strategy

Key Advantage: Since users never see the IBAN, the entire migration is a backend operation with no UI dependency and no user notification required. This makes AANI the lowest-risk migration despite having the largest user base (134.6K).

For the detailed migration plan, refer to the AANI Migration Plan document.

3.4 Use Case 4: Quantix Loan Repayment (P2)

Target: 50K users → Zand IBANs
Notification: Yes - App UI
New Users: W1-Mar 2026 | Existing Migration: W3-Mar → W2-Apr

3.4.1 Current Architecture

3.4.2 Migration Strategy (W3-Mar → W2-Apr)

API Change:

GET /api/v1/user/{userId}/iban

// Pre-migration response
{ "iban": "AE12 0351 xxxx xxxx xxxx", "bank": "FAB" }

// Post-migration response (Zand preferred)
{ "iban": "AE12 ZAND xxxx xxxx xxxx", "bank": "ZAND" }
// Fallback: returns FAB IBAN if Zand IBAN does not exist

3.5 Use Case 5: WPS Salary Credits (P3)

Target: 125 corporates → Zand IBANs
Notification: Yes - Email Trigger
New Corporates: W1-Mar 2026 | Existing Migration: W4-Mar → W3-Apr

3.5.1 Current Architecture

3.5.2 New Corporate Flow (W1-Mar)

3.5.3 Existing Corporate Migration (W4-Mar → W3-Apr)

Key Design: 30-day external deactivation + 15-day silent fallback = effective 45-day buffer period, reducing corporate migration risk. Communication via email trigger (not App UI) since WPS corporates interact through the merchant portal.

4. Cross-Team Collaboration

4.1 RACI Matrix

4.2 Key Dependencies

5. Data Migration Design

5.1 IBAN Data Model Changes

5.2 Migration State Machine

6. Risk Assessment & Fallback Strategy

6.1 Risk Matrix

6.2 Fallback Strategy

7. Monitoring & Acceptance Criteria

7.1 Key Monitoring Metrics

7.2 Migration Completion Acceptance Criteria

• [ ] 100% of active users have new IBANs assigned (Zand/PayBy/ENBD per use case)
• [ ] 100% of new users are issued new IBANs directly
• [ ] 0 successful fund-in transactions via deactivated FAB IBANs
• [ ] All API endpoints return new IBANs as default
• [ ] C&S manual transfer process terminated
• [ ] FAB channel officially decommissioned

8. Open Items