Pay by Bank is part of the UAE’s move toward a consistent Open Finance experience across banks and businesses. Using one customer-facing name across campaigns, checkout and payment journeys helps customers recognize the method and build familiarity over time. Learn more from the CBUAE

Pay by Bank lets customers pay a business directly from their bank account through a secure, guided journey without entering card details.

Customers should quickly understand:

1. What it is: a way to pay directly from their bank account.
2. Why use it: pay directly from your bank without typing card details or entering a CVV or OTP on Open Finance journeys. Eligible returning customers can use One Tap. Customers choose when and how to pay and can remove a saved bank connection anytime. Use “instant” and no-waiting-period claims only where supported.
3. What happens: choose a bank, approve the payment securely and return for confirmation.
4. Why trust it: lead with customer control, then give concrete reassurance: “You’re in full control. You choose when and how to pay. Bank-level security—with payment approval and account connection handled directly in your own banking app.” Where saving an account is available, follow with optional saving, removal anytime and reassurance that bank login details are never shared with [merchant name]. Match bank-app wording to the live journey. For AlTareq-powered UAE payments, explain that the framework is regulated by the Central Bank of the UAE.

These guidelines define shared naming, benefits and publishing guardrails. Copy library applies them to the three customer scenarios and their channels. Use the customer-ready boilerplate below as a baseline for short descriptions and FAQs, adapting it to the relevant scenario and live journey rather than inserting it unchanged into every template.

Use Pay by Bank consistently across campaigns, checkout, bank selection, status messages, FAQs and support.

Do not use as the payment-method name: Instant Bank Transfer, Bank Transfer, IBT, A2A, Open Finance payment or a merchant-specific name.

“Pay directly from your bank account” can explain the method, but should not replace its name.

Lead with what the customer gains, not the business’s cost savings. Use the following customer-facing benefit lines wherever benefits are mentioned, selecting only those that apply to the live experience:

• Less payment friction: “No card details to type. No CVV or OTP to enter. Pay directly from your bank.” For eligible returning users: “Pay with One Tap from your saved bank account. No card details. No CVV or OTP.” Add “instant” only where verified. Lead with these everyday benefits rather than card upkeep, expiry or replacement; keep OTP-free claims specific to Open Finance journeys.
• You’re in full control: “You choose when and how to pay. If you choose to save your bank account, you can remove the connection anytime.” Explain payment permission as permission to use the saved connection for future payments the customer chooses to make—not automatic payments. Do not bring payment limits into this explanation.
• Bank-level security: “Bank-level security—with payment approval and account connection handled directly in your own banking app.” Use this where the live journey supports it; do not imply every returning One Tap payment needs bank-app approval.
• No waiting period for new contacts: “Pay new contacts immediately—no waiting period.”
• A regulated UAE framework: “Pay by Bank with AlTareq operates within the UAE’s Open Finance framework, regulated by the Central Bank of the UAE.”

Avoid technical terms such as payment rails, payment initiation, SIP, RE or payment gateway.

Include the essential information customers need to understand and complete the journey. These are content requirements, not a prescribed tone of voice; adapt the wording to your brand and the live payment experience:

1. The steps: Choose Pay by Bank, select a bank, approve the payment securely and return for confirmation.
2. What to expect: Be transparent about redirects, approval steps, availability and expected wait times. Do not promise “instant” or “one click” unless that is true for the complete journey.
3. Security and control: Lead with “You choose when and how to pay”, then explain bank-level security through approval in the customer’s own banking app. Make the amount and recipient clear before approval. Where saving an account is offered, explain that it is optional and the connection can be removed anytime. Keep this short; do not use limits or technical consent language to explain payment permission.
4. Consistent cues: Keep the same name, benefit and visual cues from campaign to confirmation. Do not introduce another customer-facing product name.

Use specific privacy reassurance: “Your bank login details are never shared with [merchant name].” Do not extend this to “your information is never saved, used or seen”: merchants may receive payment or account information needed to process payments. Avoid absolute security claims such as “100% safe,” “risk-free” or “fraud-proof.”

Where One Tap is available, position it as the returning Pay by Bank experience for customers who come back with a saved account:

Use returning payment or returning experience when describing the action or journey. Do not call it a “repeat payment.” If payment permission needs explaining, say: “Payment permission lets [merchant name] use your saved bank connection for future payments you choose to make.” Saving an account does not set up automatic or recurring payments. Confirm One Tap eligibility and explain any further bank approval required.

Bank coverage applies across all three scenarios: name only currently live banks and eligible accounts. Select Pay by Bank to check support. One Tap coverage may be narrower than the wider Pay by Bank bank list.

Keep the scenarios separate

• Do not tell first-time Pay by Bank users to “set up again.” Their goal is to try Pay by Bank, not migrate.
• Legacy migration customers belong in the migration scenario, even if this is their first use of the Pay by Bank name. Do not treat them as generic first-time acquisition.
• Do not invite customers with an active eligible saved connection to save it again. Use returning-payment messaging; use reconnection messaging only when the connection has expired.
• In migration copy, do not present existing speed, card-free payment or bank approval as newly introduced benefits. Add new-benefit claims only where verified.

One Tap’s role by scenario

• Existing Pay by Bank users saving an account: eligible One Tap payments are the main benefit. Saving remains optional.
• Legacy migration: One Tap is an optional benefit only where saved accounts are live and the bank, account and payment are eligible. Keep setting up again as the primary action and retain the reconnection context.
• First-time Pay by Bank trial: optional account saving is a secondary benefit, not a requirement for trying Pay by Bank.

Across all three, saving does not set up automatic or recurring payments. Customers choose when to pay and can remove the connection anytime. Explain any further bank approval required for returning One Tap payments.

Keep Pay by Bank as the primary name. Distinguish recognition of the new name from the action needed to migrate: this is a move to a new payment journey, not merely a rename.

For legacy customers who need to migrate, explain the required action:

Confirm why the new setup is needed, what happens to the old connection, whether the legacy method remains available and any migration deadline before publishing those details. Do not invent them.

If existing users need temporary support recognizing the method, use:

Use this only for audiences familiar with the old term, including at checkout or the payment-method selection screen so returning customers can recognize their usual payment method. Keep Pay by Bank as the primary label and the old name as temporary supporting text, then remove the supporting text once the new name is established. Do not use both names indefinitely.

These recommendations are intended to guide Pay by Bank messaging, not replace your brand’s tone of voice. Adapt the wording to suit your customers and channels while keeping the payment-method name and core meaning consistent.

When writing Pay by Bank copy, we recommend:

• using clear, direct, reassuring and transparent language;
• using short sentences and everyday words;
• leading with the customer benefit, then explaining the process;
• giving one main message per screen or notification;
• using active instructions, such as “Choose your bank” rather than “A bank may be selected”;
• stating the payment status explicitly: successful, pending, unsuccessful or cancelled;
• avoiding technical language, pressure tactics and unsupported superlatives such as “fastest,” “safest” or “best”; and
• focusing on the customer experience, not only the business’s cost savings.

Use these descriptions as a baseline for customer FAQs, checkout explainers and launch communications. Adapt the wording to your brand, customer scenario and live journey while keeping Pay by Bank as the payment-method name. They are not mandatory text to insert unchanged into every template; use the scenario-specific marketing copy for account-saving upgrades, legacy migration and first-time trial.

What is Pay by Bank?

Use the OTP-free wording for Open Finance journeys and match the approval steps to the live experience.

How does Pay by Bank work?

What is AlTareq?

Why am I seeing AlTareq when I pay?

Before publishing, confirm that the copy matches the live implementation and approved legal guidance, especially:

• participating-bank coverage;
• whether the journey redirects or remains embedded;
• whether the customer returns automatically;
• expected payment timing, including any “instant” claim for One Tap;
• One Tap eligibility, saved-account behavior and approval experience;
• whether saving an account is optional and where customers can remove the connection anytime; keep payment-permission explanations focused on customer choice, not limits;
• bank-app approval and account-connection steps, supported authentication methods and any further approval required for One Tap; Open Finance journeys do not require OTPs, so pair “No OTP” with “No CVV” in card-friction copy;
• support for paying new contacts and any beneficiary waiting period;
• use of CBUAE, AlTareq or Nebras names and assets;
• security, protection and data-handling statements; and
• claims about speed, conversion or savings.

State the confirmed payment status explicitly. Use these lines once the status is known.

The templates use [action] and [object]. Replace them with the words for the use case, and check the timing claim each one implies.