[Due for payment 2026-06-18] [$250] Canadian phone numbers rejected in deposit-only bank account setup

[MelvinBot]

Canadian users are unable to add a deposit-only personal bank account because the phone number validation requires a US phone number. The form silently rejects valid Canadian phone numbers at the client-side validation step, preventing the AddPersonalBankAccount API call from ever being made.

Slack thread: https://expensify.slack.com/archives/D0AGYJN9H47/p1778253602744309

Current behavior

In PhoneNumberStep.tsx:39, the phone validation checks both isValidPhoneNumber() AND isValidUSPhone():

if (!isValidPhoneNumber(phoneNumberWithCountryCode) || !isValidUSPhone(e164FormattedPhoneNumber)) {
    errors.phoneNumber = translate('common.error.phoneNumber');
}

isValidUSPhone() only accepts numbers with region codes: US, PR, GU, VI, AS, MP. Canadian numbers (+1 with CA region code) are rejected even though Canada shares the +1 country calling code.

Expected behavior

Canadian phone numbers should be accepted in the deposit-only bank account setup flow (at minimum). The file is under InternationalDepositAccount/, which implies international support was intended.

Origin

This US-only phone validation was introduced in PR #75179 ("Change for personal bank account setup") by TaduJR on 2025-11-14.

---

Proposal

What is the root cause of that problem?

The isValidUSPhone() check in PhoneNumberStep.tsx uses parsePhoneNumber and compares the resolved regionCode against a hardcoded list of US territories (US, PR, GU, VI, AS, MP). Canada has its own region code CA despite sharing the +1 calling code with the US, so Canadian numbers are rejected.

What changes do you think we should make in order to solve the problem?

Add CA to the accepted region codes in the validation for the InternationalDepositAccount phone number step. Specifically:

1. In PhoneNumberStep.tsx:39, replace the isValidUSPhone() call with a new validation function (e.g., isValidNANPPhone()) that accepts both US territory AND Canadian region codes — or simply add CA to the validUSRegionCodes array in ValidationUtils.ts:289.

The safer approach is to create a separate function or add a parameter to isValidUSPhone rather than modifying its existing behavior, since other callers may intentionally require US-only validation.

What alternative solutions did you explore?

• Removing the isValidUSPhone check entirely and relying only on isValidPhoneNumber() — this would accept any international phone, which may be too permissive if the backend requires NANP numbers.
• Adding a separate isValidCanadianPhone() check — unnecessary since the real fix is just expanding the accepted region codes for this specific flow.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022057369010872431986
• Upwork Job ID: 2057369010872431986
• Last Price Increase: 2026-05-21

Issue Owner

Current Issue Owner: @Ollyws

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @Ollyws (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022057369010872431986

[aswin-s]

Proposal

Please re-state the problem that we are trying to solve in this issue.

When a Canadian user (or any non-US user) tries to add a personal deposit-only bank account via the InternationalDepositAccount flow, the phone-number substep silently rejects their valid number, blocking the submit and preventing the AddPersonalBankAccount API call. Expected behavior: the international deposit flow should accept any valid international phone number — Canadian phones (+1, region code CA) at minimum — since the flow is explicitly named and scoped as "International".

What is the root cause of that problem?

In src/pages/settings/Wallet/InternationalDepositAccount/PersonalInfo/substeps/PhoneNumberStep.tsx:39, validation requires both isValidPhoneNumber and isValidUSPhone. isValidUSPhone at src/libs/ValidationUtils.ts:289 only accepts region codes US, PR, GU, VI, AS, MP, so any non-US region (including CA) fails. This US-only check was added during the personal-bank-account refactor in PR #75179, but it is inappropriate inside the InternationalDepositAccount flow, whose purpose is international account setup.

What changes do you think we should make in order to solve the problem?

1. In src/pages/settings/Wallet/InternationalDepositAccount/PersonalInfo/substeps/PhoneNumberStep.tsx:39, drop the isValidUSPhone(e164FormattedPhoneNumber) conjunct so the international flow validates with isValidPhoneNumber only (which already returns parsedPhoneNumber.possible for any region).
2. Remove the now-unused isValidUSPhone and formatE164PhoneNumber-for-validation imports/locals if they become unreferenced after the change (keep formatE164PhoneNumber for the submit path — it is still used on submit).
3. No change needed in ValidationUtils.ts; isValidUSPhone legitimately stays US-only for its other callers (AdditionalDetailsStep.tsx, PhoneNumberBusiness.tsx for the USD ReimbursementAccount flow), where US-only is correct.
4. No platform twins — PhoneNumberStep.tsx is shared across Web/iOS/Android.

What alternative solutions did you explore?

Adding CA (and other +1 territories) to validUSRegionCodes in ValidationUtils.ts — rejected because it would silently broaden a function named isValidUSPhone for unrelated US-only callers (USD ReimbursementAccount Requestor/Business steps), risking regressions there. Scoping the fix to the international flow is safer and matches that flow's intent.

[dilshodmackbook-sketch]

Proposal

What is the root cause of that problem?

isValidUSPhone accepts US territories that share the +1 calling code but explicitly excludes CA:

https://github.com/Expensify/App/blob/main/src/libs/ValidationUtils.ts#L289

const validUSRegionCodes: string[] = [CONST.COUNTRY.US, CONST.COUNTRY.PR, CONST.COUNTRY.GU, CONST.COUNTRY.VI, CONST.COUNTRY.AS, CONST.COUNTRY.MP];

The deposit-only personal bank account step calls it directly:

https://github.com/Expensify/App/blob/main/src/pages/settings/Wallet/InternationalDepositAccount/PersonalInfo/substeps/PhoneNumberStep.tsx#L39

So a valid Canadian number like +1 416-555-1234 resolves to regionCode = 'CA', fails the list check, and the user sees the generic phone-number error. The same function is also called from EnablePayments, ReimbursementAccount/USD/BusinessInfo, and several other US-only flows — those legitimately need a US-only check, so we can't relax isValidUSPhone itself.

The file lives under InternationalDepositAccount/ and the field is the user's personal contact phone for identity verification, not the bank's routing geography. There's no business reason this specific flow needs US-only validation.

What changes do you think we should make in order to solve the problem?

Add a separate validator for NANP (North American Numbering Plan) phone numbers that accepts both US territories and Canada, and use it only in the international deposit-account flow:

1. New validator in ValidationUtils.ts:

  function isValidUSPhone(phoneNumber = '', isCountryCodeOptional?: boolean): boolean {
      const phone = phoneNumber || '';
      const regionCode = isCountryCodeOptional ? CONST.COUNTRY.US : undefined;

      if (regionCode && !Str.isValidPhoneFormat(phone)) {
          return false;
      }

      const parsedPhoneNumber = parsePhoneNumber(phone, {regionCode});
      const validUSRegionCodes: string[] = [CONST.COUNTRY.US, CONST.COUNTRY.PR, CONST.COUNTRY.GU, CONST.COUNTRY.VI, CONST.COUNTRY.AS, CONST.COUNTRY.MP];
      return parsedPhoneNumber.possible && validUSRegionCodes.includes(parsedPhoneNumber.regionCode ?? '');
  }

+ /**
+  * Validates phone numbers from the North American Numbering Plan (+1 country code).
+  * Accepts US, US territories, and Canada. Use this for flows where the phone number
+  * identifies the user (e.g. wallet/bank verification) rather than US-bound business logic.
+  */
+ function isValidNANPPhone(phoneNumber = '', isCountryCodeOptional?: boolean): boolean {
+     const phone = phoneNumber || '';
+     const regionCode = isCountryCodeOptional ? CONST.COUNTRY.US : undefined;
+
+     if (regionCode && !Str.isValidPhoneFormat(phone)) {
+         return false;
+     }
+
+     const parsedPhoneNumber = parsePhoneNumber(phone, {regionCode});
+     const validNANPRegionCodes: string[] = [CONST.COUNTRY.US, CONST.COUNTRY.PR, CONST.COUNTRY.GU, CONST.COUNTRY.VI, CONST.COUNTRY.AS, CONST.COUNTRY.MP, CONST.COUNTRY.CA];
+     return parsedPhoneNumber.possible && validNANPRegionCodes.includes(parsedPhoneNumber.regionCode ?? '');
+ }

2. Use it in the international deposit-account step (PhoneNumberStep.tsx):

- import {getFieldRequiredErrors, isValidPhoneNumber, isValidUSPhone} from '@libs/ValidationUtils';
+ import {getFieldRequiredErrors, isValidNANPPhone, isValidPhoneNumber} from '@libs/ValidationUtils';
  ...
- if (!isValidPhoneNumber(phoneNumberWithCountryCode) || !isValidUSPhone(e164FormattedPhoneNumber)) {
+ if (!isValidPhoneNumber(phoneNumberWithCountryCode) || !isValidNANPPhone(e164FormattedPhoneNumber)) {
      errors.phoneNumber = translate('common.error.phoneNumber');
  }

The other callers of isValidUSPhone (EnablePayments, AdditionalDetailsStep, PhoneNumberBusiness) keep using US-only — those are tied to US-specific compliance flows (US bank routing, business EIN, etc.) where Canada genuinely isn't supported, so leaving them untouched is correct.

Caveat

The backend API behind this flow (AddPersonalBankAccount) needs to actually accept Canadian phone numbers downstream — if the server still rejects them after client validation passes, the user just sees the error later instead of at the form. I'd suggest a quick check with the backend team to confirm there's no parallel server-side US-only check, but the client fix is independently correct.

[KJ21-ENG]

Proposal

Please re-state the problem that we are trying to solve in this issue.

Canadian users cannot complete the deposit-only personal bank account flow because the phone-number step rejects valid Canadian numbers before the form can submit AddPersonalBankAccount.

What is the root cause of that problem?

The international deposit account phone step first builds a +1 number from the user's input and selected country code, then requires both generic phone validity and isValidUSPhone() to pass:

App/src/pages/settings/Wallet/InternationalDepositAccount/PersonalInfo/substeps/PhoneNumberStep.tsx

Lines 35 to 41 in eaaffe3

	if (values.phoneNumber) {
	const phoneNumberWithCountryCode = appendCountryCode(values.phoneNumber, countryCode);
	const e164FormattedPhoneNumber = formatE164PhoneNumber(values.phoneNumber, countryCode);
	if (!isValidPhoneNumber(phoneNumberWithCountryCode) || !isValidUSPhone(e164FormattedPhoneNumber)) {
	errors.phoneNumber = translate('common.error.phoneNumber');
	}

isValidUSPhone() parses the E.164 number and only allows region codes for the US and several US territories:

App/src/libs/ValidationUtils.ts

Lines 275 to 291 in eaaffe3

	function isValidUSPhone(phoneNumber = '', isCountryCodeOptional?: boolean): boolean {
	const phone = phoneNumber || '';
	const regionCode = isCountryCodeOptional ? CONST.COUNTRY.US : undefined;
	// When we pass regionCode as an option to parsePhoneNumber it wrongly assumes inputs like '=15123456789' as valid
	// so we need to check if it is a valid phone.
	if (regionCode && !Str.isValidPhoneFormat(phone)) {
	return false;
	}
	const parsedPhoneNumber = parsePhoneNumber(phone, {regionCode});
	// US territories share the +1 country calling code but have their own ISO region codes.
	// We accept these as valid US phone numbers for wallet/bank account verification.
	const validUSRegionCodes: string[] = [CONST.COUNTRY.US, CONST.COUNTRY.PR, CONST.COUNTRY.GU, CONST.COUNTRY.VI, CONST.COUNTRY.AS, CONST.COUNTRY.MP];
	return parsedPhoneNumber.possible && validUSRegionCodes.includes(parsedPhoneNumber.regionCode ?? '');
	}

Canada shares the NANP +1 calling code, but parsed Canadian numbers have region code CA. The current unit test confirms that +14165551234 is intentionally treated as false by isValidUSPhone() today, so the deposit-only flow blocks Canadian phone numbers client-side:

App/tests/unit/ValidationUtilsTest.ts

Lines 580 to 582 in eaaffe3

	expect(isValidUSPhone('+14165551234')).toBe(false);
	});

What changes do you think we should make in order to solve the problem?

Add a NANP-scoped validation helper instead of changing isValidUSPhone() globally, because existing callers in USD reimbursement and Enable Payments may rely on the current US-only behavior.

Concretely:

• In src/libs/ValidationUtils.ts, extract the current allowed US/territory region list into a shared constant and add a new helper such as isValidNANPPhone(phoneNumber = '', isCountryCodeOptional?: boolean).
• Have the new helper use the same parse/format guard behavior as isValidUSPhone(), but allow CONST.COUNTRY.CA in addition to the existing US/territory region codes.
• Keep isValidUSPhone() behavior unchanged by either leaving it on the US/territory list or implementing it as the strict variant over the same internal utility.
• Update only src/pages/settings/Wallet/InternationalDepositAccount/PersonalInfo/substeps/PhoneNumberStep.tsx to use the NANP helper after isValidPhoneNumber().
• Add unit coverage proving isValidUSPhone('+14165551234') remains false while isValidNANPPhone('+14165551234') is true, and add/adjust a focused validation test for the international deposit phone step if an existing test harness covers these substeps.

This keeps the fix limited to the deposit-only international bank-account flow while preserving stricter US-only validation elsewhere.

What alternative solutions did you explore? (Optional)

I considered adding CA directly to validUSRegionCodes, but that would silently broaden every existing isValidUSPhone() caller, including flows whose names and copy suggest strict US validation.

I also considered removing the isValidUSPhone() check from the international deposit step and relying only on isValidPhoneNumber(), but that would accept all possible international numbers. A NANP helper is narrower and matches the Canadian failure case without assuming backend support for every country.

[MelvinBot]

Issue Analysis

Root Cause: PhoneNumberStep.tsx:39 in the InternationalDepositAccount flow requires both isValidPhoneNumber() AND isValidUSPhone(). isValidUSPhone() only accepts region codes US, PR, GU, VI, AS, MP — Canadian numbers (region code CA) are rejected despite sharing the +1 calling code.

Recommended Fix: Remove the isValidUSPhone() check from the InternationalDepositAccount PhoneNumberStep.tsx validation. isValidPhoneNumber() alone is sufficient — it validates character format and uses libphonenumber's possible check, which works for any country. The other 3 callers of isValidUSPhone (EnablePayments wallet flows, USD ReimbursementAccount) are legitimately US-only and should remain unchanged.

Investigation details

Data flow:

1. User enters phone number → appendCountryCode prepends +1 (default)
2. formatE164PhoneNumber formats to E.164 (e.g., +14165551234)
3. isValidPhoneNumber() → passes (Canadian numbers are valid per libphonenumber)
4. isValidUSPhone() → parses E.164, gets regionCode: 'CA' → fails because CA ∉ [US, PR, GU, VI, AS, MP]

Other callers of isValidUSPhone (all legitimately US-only):

• EnablePayments/PersonalInfo/substeps/PhoneNumberStep.tsx:32 — Expensify Wallet
• EnablePayments/AdditionalDetailsStep.tsx:97 — Expensify Wallet
• ReimbursementAccount/USD/BusinessInfo/subSteps/PhoneNumberBusiness.tsx:31 — USD reimbursement

Alternative considered: Adding CA to validUSRegionCodes — rejected because it would broaden a function named isValidUSPhone for unrelated US-only callers. Scoping the fix to the international flow is safer.

Origin: The US-only check was introduced in PR #75179 and appears to have been copy-pasted from the EnablePayments PhoneNumberStep.

---

Next Steps: Reply with @MelvinBot implement this to create a draft PR, or @MelvinBot <your feedback> to refine this analysis.

[efanious]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[github-actions]

⚠️ @efanious Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.

[efanious]

Proposal: Genuine International Support for Deposit-Only Phone Validation

Problem Statement

The InternationalDepositAccount flow is artificially restricted to NANP (+1) region codes despite being named and scoped for international use. Canadian users and any non-NANP users are blocked client-side. The underlying issue is philosophical: the flow assumes it must validate that a phone number is "acceptable" to the backend, but that's the backend's job. The client should only validate that input is well-formed.

Root Cause

PhoneNumberStep.tsx line 39 chains two validation checks:

• isValidPhoneNumber (generic format check)
• isValidUSPhone (region code whitelist check)

The second check is over-protective. It assumes the backend cannot handle non-US numbers, but this assumption lives in client code and blocks legitimate international users before the form ever submits. If the backend truly rejects Canadian numbers, it will reject at the API layer—that's the right place for that decision.

Recommended Change

Remove the region-code restriction entirely. In src/pages/settings/Wallet/InternationalDepositAccount/PersonalInfo/substeps/PhoneNumberStep.tsx:

Current validation (line 39):

if (!isValidPhoneNumber(phoneNumberWithCountryCode) || !isValidUSPhone(e164FormattedPhoneNumber)) {
    errors.phoneNumber = translate('common.error.phoneNumber');
}

Change to:

if (!isValidPhoneNumber(phoneNumberWithCountryCode)) {
    errors.phoneNumber = translate('common.error.phoneNumber');
}

That's it. Remove the isValidUSPhone check and remove that import.

Why This Works

isValidPhoneNumber already uses libphonenumber's built-in validation, which:

• Validates character format
• Checks the number is possible (valid digit length, prefix patterns, etc.)
• Works for every country libphonenumber supports

It doesn't restrict by region code, so a valid Canadian number (+1 416 555 1234) passes. A valid UK number (+44 20 1234 5678) passes. An invalid Russian number fails. That's exactly the right scope for client-side validation.

What Happens If Backend Doesn't Support a Region

The AddPersonalBankAccount API call goes through, the server rejects it (either with a specific "region not supported" error or a generic validation error), and the error surfaces back to the user. The user sees the rejection and understands it's a backend limitation, not a bug.

This is better UX than silent client rejection because:

• The error comes from the authoritative source (the backend)
• The user is not blocked by assumptions baked into client code
• If backend support expands later, it works immediately (no client patch needed)
• Debugging is clearer (the rejection is real, not preventive)

No Change Needed Elsewhere

The other three callers of isValidUSPhone (EnablePayments wallet flows, USD reimbursement) are intentionally US-only. Those flows can keep using isValidUSPhone because they are tied to US-specific compliance (EIN, US bank routing). Don't touch them.

Edge Case: Formatting on Submit

The line const e164FormattedPhoneNumber = formatE164PhoneNumber(phoneNumberWithCountryCode); still runs before submit. This already works for any country—formatE164PhoneNumber uses the selected country code dropdown to build the E.164 string, so Canadian inputs format correctly.

Testing

Update or add a test in the test file that exercises the international deposit phone step:

• Assert that a valid Canadian number (+1 416 555 1234) passes validation
• Assert that a valid UK number (+44 20 1234 5678) passes validation
• Assert that an invalid number (garbage input) still fails validation

Keep the existing isValidUSPhone unit tests unchanged—they still belong to that function and its specific callers.

Summary

Stop assuming what the backend accepts. Validate format client-side, let the backend enforce geography policy. This unblocks Canadian users immediately, scales to any country, and keeps validation logic in the right place.