Frequently Asked Questions

APIs (Application Programming Interfaces) allow systems and apps to share information with each other in real time.

BMO APIs let you connect your accounting, treasury management and other financial systems to your Online Banking for Business accounts. That connection gives you access to your real-time banking activity and lets you make transactions directly in the programs you use every day – without having to export data, upload files, or sign in to Online Banking for Business. You can also use our APIs to build your own features to integrate our banking services directly within your own applications and platforms. Our APIs make your banking data work for you.

BMO APIs let you access and use your account data and payment services whenever and wherever you want. Clients like you are using our APIs to:

• See real-time balances for all accounts
• Retrieve day-end, month-end and year-end balances for all accounts
• Pull transaction histories
• Review transactions based on a specific set of criteria
• Replace BAI files and other settlement reports and processes
• Retrieve images of deposited cheques and other items
• Validate third-party accounts before creating transactions
• Send or collect payments
• Process in-app purchases and fund digital wallets
• Receive real-time payment status updates by API, email or text message.

Once you create an account on the BMO Developer Portal, you can:

• Add and manage access for your team members
• Explore our APIs and detailed documentation
• Use our API Explorer to try our APIs and get sample request code
• Access your Sandbox credentials for your applications
• Generate Sandbox access tokens
• Connect your applications directly to our Sandbox
• Request access to our Pre-Production environment
• Manage test data for Pre-Production testing
• Request access to Production environment

If you're an Online Banking for Business customer, you can use our APIs to connect your BMO accounts and create payments right from your accounting, treasury management and other financial systems.

You can safely experiment with our APIs in our Sandbox and test them in our Pre-Production environment at no cost. When you’re ready to launch your application, please contact us to discuss pricing.

To explore our APIs in the Sandbox and Pre-Production environments, you'll need to apply for an organization account on the BMO Developer Portal. Once we've reviewed and approved your application, we'll send you an email with your account credentials and instructions for adding your team members.

When you apply and are approved for an organization account, we'll send you two emails: one with setup details and one with a link to create a password. If you don't see these emails, please check your spam folder. If you still can't find them, please contact us.

To try our Sandbox in your own application, you'll need an API key. This API key, along with the Client ID and Client secret displayed under "My applications", can be used directly in your application to communicate with our Sandbox environment. Depending on your language preferences, you can choose between an API key for English code responses and one for French responses.

Once you have your API key, use our Authorize API or go to our API Explorer on this site to generate your access token. You can use this token and the other Sandbox credentials to try any of our APIs.

1. In the BMO Developer Portal, select your username and choose My Apps from the dropdown.
2. Select the Register New App button.
3. Fill in the details and select Register New App.

Once you have your key, go to our sandbox and generate an Access Token. You can use this token to test any of your registered apps.

Your API key is one of the credentials we assign to you. It lets us verify your identity and determine which application is trying to connect to our APIs.

In our Sandbox, the API key can be shared for all your applications and can be found under “My applications” along with other credentials. Here, we also offer 2 distinct API keys that will determine the language you want to receive your code responses in.

For our Pre-Production and Production environments, we'll send you a separate, unique API key for each application.

All our APIs use the standard OAuth 2.0 framework.

To get authorized to make calls, please check our Authorize documentation. It contains all the information you’ll need to implement a three-legged OAuth flow.

You need to generate and use an access token to authorize your application to connect to our Sandbox, Pre-Production or Production environments. You can generate Sandbox access tokens in our API Explorer tool on this site or use the Authorize API. For Pre-Production and Production environments, you need to generate your access tokens using our Authorize API only. For more details, please view our Authorize API documentation

The credentials you use depend on whether you're connecting to our Sandbox, Pre-Production or Production environment.

In our Sandbox and Pre-Production environments, all sign-in credentials are pre-filled for you.

When you're ready to launch your application and grant access to your accounts, please use your existing Online Banking for Business credentials.

When you make a GET call to our system, specifically Search for Accounts, you'll be returned a list of authorized accounts. For security reasons, these accounts will be identified with a unique account ID that is different from the account number.

To see which account is associated with the account ID returned, check the account_number field in the body of the return.

When you connect an application in production, you’ll be able to see the same accounts you’re entitled to in Online Banking for Business.

As part of the authorization flow, you’ll be able to choose which accounts you’d like to grant access to.

Apart from the Authorize API to give your application secure access to our servers, you’ll only need the Image Retrieval API to retrieve deposit images.

Once your application has been authenticated using the Authorize API, you can start your search for deposit images. Here's how it works:

• Get a list of your authorized Online Banking for Business accounts.
• Specify the account number, date range and item type. You can also add other search criteria.
• From the index of available images, choose the ones you want to retrieve.

The process is the same for Canadian and U.S. items.

You can request images of deposited items as far back as 7 years. To retain them even longer, you can use the API to automatically download and store them in your own archive.

Apart from the Account Validation API to verify account ownership, you’ll also need the Authorize API to give your account secure access to our servers and the Encryption API to protect sensitive information from end-to-end.

Currently, this API only supports U.S. savings and deposit accounts.

Each call can validate up to 100 accounts. There’s no limit for the calls you submit.

You can choose if you want to check account ownership, risk level or both. Simply submit the details you want us to check.

ACH payments may still be rejected due to downstream business validations that typically occur after the initial request acceptance. Common reasons for rejection include:

• beneficiary bank restrictions
• incorrect beneficiary information
• limit validations
• sanctions screening

If you are unable to resolve the issue, please email us at

tps.apisupport@bmo.com

Nacha Operating Rules & Guidelines provide a defined list of permitted special characters that must be followed during transaction processing.

Using characters that are not allowed may result in the batch or payment being rejected. See ACH specifications for all approved special characters.

Today, we have the Parent tag for "Category Purpose code" to capture the purpose of the payment and that field is limited to 4 characters.

Since the micro-deposit Nacha specification requires the phrase ACCTVERIFY to be added for all micro deposit transactions, the child tag "Category Purpose proprietary" will be mapped to Company Entry Description with the limit of 35 characters.

This will allow client micro-deposit API transactions to be formatted so they are Nacha compliant. This change will go into production in July 2026. And it will be supported in the BMO Developer Portal for testing in the Fall 2026.

EFT payments may still be rejected due to downstream business validations that typically occur after the initial request acceptance. Common reasons for rejection include:

• beneficiary bank restrictions
• incorrect beneficiary information
• limit validations
• sanctions screening

If you are unable to resolve the issue, please email TPS API Support at

tps.apisupport@bmo.com

Instant Payments may still be rejected due to downstream business validations that typically occur after the initial request acceptance. Common reasons for rejection include:

• beneficiary bank restrictions
• incorrect beneficiary information
• limit validations
• sanctions screening

If you are unable to resolve the issue, please email TPS API Support at

tps.apisupport@bmo.com

Yes, you can choose how the fulfillment link is delivered. We can either send the link directly back to your system, send it by email to the respondent, or do both. This gives you full control and allows you to suppress the email notification if it doesn’t fit your experience or workflow.

Yes, you can specify the displayed requestor name in the payload.

The payment will remain outstanding until question and answer is completed, until the payment expires, or until the payment is cancelled.

The recipient has 3 attempts.

The Instant Payments API has payments settled using Interac e-transfers. Interac e-transfers are final and irrevocable payments. This means that unlike cheques or direct deposit transactions which potentially can be returned or reversed, instant payments cannot be reversed. There can be certain exceptions, such as misdirected funds, fraud issues, and AML investigations.

Interac has been expanding the number of financial institutions that are able to receive account number routed payments. A full list can be found on the Interac website. At the same time, the "Get payment options" API endpoint provides the ability to send us an API call along with the recipient’s account number and we will respond back in real time if that financial institution supports account number routing.

Even if the request passes schema and format validation, wire payments may still be rejected due to downstream business validations. These validations typically occur after initial request acceptance. Common reasons include:

• invalid or non‑existent BICs
• beneficiary bank restrictions
• currency or corridor limitations
• sanctions screening
• missing required settlement data.

A wire payment may remain in a pending or processing status due to cut-off times, intermediary bank processing, compliance checks, or downstream settlement timing. Status updates are provided as they become available through the API.

Each wire payment submission must include a MessageIdentification, which is a unique API identifier used to identify the payment request. The value must be no more than 35 characters and must be unique within a 6-month period. Duplicate submissions are not permitted and will fail with a pain.002 response. To retry a wire payment, clients must submit a new request using a new, unique MessageIdentification.

Sandbox does not perform full sanctions screening, network validations or live bank-to‑bank routing. Production failures are commonly related to real-world bank data, compliance checks or corridor restrictions that are not fully simulated in Sandbox.

The Ultimate Debtor identifies the person or organization that ultimately provides the funds for the wire payment. This information is only included when the appropriate entitlements are enabled. If this information is missing, your organization’s setup may not have the required permissions. Please contact your sales representative to confirm your configuration.

Note: For customer types Money Service Business (MSB), TPPP – Other, or TPPP Third Party Sender, Ultimate Debtor information is required. If it is not provided, the wire payment will be rejected.

No, wire payments created via API do not appear in Online Banking for Business

Providing the full "Creditor Address" is highly recommended to assist with any compliance review.

U.S. clients – Only the Creditor Town Name/City and Country are mandatory fields (beginning Nov 2026) when sending a domestic or international (non-Canada) wire payment.

When sending to a Creditor located in Canada, the full address must be provided.

* Pre-Production is currently validating the full Creditor address for all countries, although this is not a requirement in Production.

Canadian clients – Full Creditor Address is mandatory.

TTL for tokens are the same across Sandbox, Pre-production and Production environments:

• Authorization codes expire after 5 minutes
• Access tokens expire after 15 minutes
• Refresh tokens expire after 1 month

Authentication for both Sandbox and Pre-production relies on test customer credentials.

• To find your Sandbox test credentials, access BMO Developer Portal > Workspace > My applications.
• For Pre-production test credentials, we'll email them to you. See our OAuth Client Guide

Production authentication relies on specific production credentials which grant access to our production environment. You receive these by Secure Mail.

Yes, BMO issues a new refresh token every time one is exchanged at the /oauth20/token endpoint. The new refresh token is valid for 1 month (30 days). The old token will no longer be valid.

If your APIs are not actively used for a period of time, your access credentials may expire for security reasons. When this happens, you’ll need to complete the authorization and consent flow again to restore access. This helps ensure credentials are only active when they are being used.

Consent check failures depend on both the type of payment (payment rail) and the level at which the consent fails.

• If consent fails at the OLBB ID level, the entire message fails for all payment rails.
• If consent fails at the account, EFT Account ID, or ACH Company ID level, the outcome depends on the payment rail.
  • For ACH, a consent failure at the ACH Company ID level causes only the affected batch—and all transactions within that batch—to fail, not the entire message.
  • For EFT, Wires, and Interac (Instant Payments), an account level consent failure results in the entire message failing.

Consent is validated using exact matches. If the account number, ACH Company ID, or EFT Account ID in your request does not exactly match what was authorized during consent, the request will fail. This includes differences in formatting or length.

Encrypted payloads should use Base64 encoding. If your integration uses Base64URL encoding, the request may fail. Ensuring the correct encoding format is important for successful encryption and decryption.

We follow a model where you:

• generate a symmetric CEK
• encrypt it using BMO’s public key (retrieved from the encryption key endpoint)
• send the encrypted CEK to BMO in the x-crypto-key header

BMO decrypts the CEK with its private key and uses the same CEK to encrypt the response sent back to you. Because you created the CEK and hold it, you can decrypt the response using that key.

Key Direction Summary:

• BMO → Client: BMO public key
• Client → BMO: Encrypted CEK
• Client keeps: CEK (used to decrypt responses)

In Production, each public key is valid for 120 days. To help ensure continuity, BMO automatically rotates keys 7–10 days before they expire. Clients are responsible for retrieving and using the new public key before the current one expires. The public key API response includes an expiry timestamp, so you can easily track when a refresh is required.

Recommended ways to manage key rotation

These options ensure your integration continues to work smoothly without interruption due to key expiration.

Option 1: Cache and refresh (recommended)

• Securely store the public key.
• Monitor the expiration timestamp.
• Retrieve a new key before the current one expires.

Option 2: Scheduled retrieval

• Retrieve the public key on a regular schedule (for example, daily or weekly).
• Always use the most recent key returned by the API.

Please email us at

tps.apisupport@bmo.com

Sandbox and Pre-Production are designed to support testing and onboarding, but it does not always behave exactly like Production.

While the intent is to match as much as possible, there may be some slight differences depending on the version.

In the event you run into an issue, please refer to the Sandbox and Pre-Production guides on the BMO Developer Portal.

If you're unable to resolve the issue, please email us at

tps.apisupport@bmo.com

Schemas define the expected structure of data—what fields are allowed, which ones are required, their formats, and any rules they must follow. They are used to validate requests and responses, ensuring data is complete, correctly formatted, and consistent so systems can process it reliably.

Schemas can be found by emailing us at tps.apisupport@bmo.com

At this time, virtual accounts are not supported with API payment creation or account information

No, E2E ID will not report on your banking statement (Unique ID per transaction).

Interac:

• E2E ID will appear on the bank statement for sent payments.
• E2E ID will not appear on the bank statement for fulfilled Request money transactions.

ACH: E2E ID will appear in your Pain.002 and account info reporting/BAI

EFT: The last 19 characters of E2E ID will be mapped for payment processing and will appear on the Originator's Cross Reference in Online Banking for Business.

Wire Payments: The E2E ID will be displayed under the "RFB" tag via Account Information Reporting/BAI

It does not report back in bank or customer reference fields.

Payment status codes indicate where your payment is in its lifecycle. While specific processing steps may vary by payment type, the definitions below apply consistently across the supported payment types.

Note: Not all payment types support every status code. Some statuses apply only to specific payment types, as outlined below.

ACTC – Accepted Technical Validation Payment has been successfully received and passed all required technical and business validations. This is the first positive status for all payment types.

RJCT – Rejected Payment was rejected and cannot be processed further. This status may be returned at any stage of the payment lifecycle for all payment types.

ACCP – Accepted (Pre Processing Completed) Payment has passed validations and is ready for processing. This status is applicable only to ACH payments.

ACSP – Accepted Settlement in Process Payment is currently being processed or settled. This status applies to all payment types.

ACSC – Accepted Settlement Completed Payment processing and settlement have been successfully completed by BMO. For ACH, EFT, and Wire Payments, this represents the final processing stage.

Note: ACH and EFT payments may still be returned after this status.

CANC – Cancelled Payment was successfully cancelled. This status applies to EFT, ACH, and Interac payments.

ACCC – Accepted Credit Completed Settlement has been completed and the payment has been processed at the beneficiary’s end. This status is applicable only to Interac payments.

PATC – Partially Accepted Technical Check A partial or interim acceptance status used during reversals, updates, or delete processes. This status is applicable only to ACH payments.

• Header Optional, identifies the underlying internal application linked to the API in question: REPLACE_THIS_VALUE' \ : Optional, Identifies if the request originates from a BMO internal application

  Values:

  • For ACH Payments, it should be 80613
  • For Electronic Funds Transfer (EFT), it should be 87335
  • For Wire Payments, it should be 87102
  • For Instant Payments (Interac), it should be 87679
• header 'x-fapi-customer-ip-address: REPLACE_THIS_VALUE' \ Optional, End user public IP
• header 'x-fapi-customer-last-logged-time: REPLACE_THIS_VALUE' \ Optional, Timestamp of last user login
• header 'x-fapi-customer-user-agent: REPLACE_THIS_VALUE' \ Optional, Describes what type of client the PSU is using (browser vs mobile app). The client may populate this field with the User-Agent header string if browser is being used. If the mobile app is being used then the x-fapi-customer-user-agent content must be different from browser based user-agent strings.
• header 'x-fapi-financial-id: REPLACE_THIS_VALUE' \ is 001 for all payment types
• header 'x-fapi-interaction-id: REPLACE_THIS_VALUE' \ : Required. This is a way to identify the request. This gives a unique ID to the API call and in the response, we will return the same ID. Makes it easier to trace and debug especially if there are a lot of calls happening at the same time. May be same as x-request-id if no session linking is needed
• header 'x-request-id: REPLACE_THIS_VALUE’ \ Required, and unique per request. Identifies each individual API request for tracing and support

The system is designed to recognize when the same payment request is submitted more than once.If both the message ID and all payment details are the same, the payment will not be processed again. Instead, the system will return the same status that was provided for the original payment, ensuring the payment is only handled once.If the same message ID is reused but the payment details are different, the request is treated as invalid and will be rejected, as each message ID must uniquely represent a single payment