A corporate makes periodic payments to a supplier for services rendered. A single payment can sometimes cover multiple invoices. With ISO 20022, a payment can be sent with remittance data that details one or multiple invoices that a single payment is intended to cover. The vendor can receive confirmation of the payment credited to their account and information on what the payment is for, all at the same time.

A corporate disburses funds to customers by submitting a bulk payments file to their financial institution. With ISO 20022 capability, each payment message can carry data on what the payment is for (e.g., customer account number), invoice number and any adjustments such as early payment discounts.

A biller sends electronic invoices with ISO 20022 request-to-pay functionality for monthly payments from customers who do not wish to set up pre-authorized debits (PADs) from their bank account. Payment links in the e-invoices enable customers to initiate payments with data fields pre-populated with info about the payment (e.g., invoice number).

If a company makes a repetitive payment, a Telco can use the historical payment to match and automatically apply a payment by reconciling between bank deposit and email. 

A Telco disburses refunds for multiple clients by submitting a bulk payments file to their financial institution. With ISO 20022 capability, each payment message can carry data on what the payment is for, including customer or invoice number and any adjustments (e.g., late payment fees).

A Telco sends a payment request using ISO 20022 request-to-pay functionality to a customer for their monthly bill. The customer accepts by clicking on a payment initiation link in the message. A payment instruction is auto-populated with remittance information (e.g., customer/invoice number) that was part of the original payment request message. Funds are immediately transferred from customer to telco without the customer sharing any bank account details.

A telco credits prepaid minutes to its prepaid mobile users who are at the most fraudulent risk for telcos due to stolen credit cards usage. With ISO 20022 Telco providers could instantly receive payment and rich remittance data from prepaid users thus being able to instantly credit prepaid minutes without worrying about fraudulent payments (stolen credit cards).

A L&H insurer makes a payment to an MGA for commission fees owed that cover multiple corporate clients and coverages. With ISO 20022 payments, remittance data providing a breakdown can travel with the payment, which can be extracted to enable automated reconciliation when the payment is made.

An insurer makes a periodic payment to a preferred vendor that covers multiple invoices. With ISO 20022, a single payment can be sent with remittance data that details all the invoices that a single aggregated payment is intended to cover. The vendor can receive confirmation of the payment credited to their account and information on what the payment is for at the same time.

An insurer makes a payment to a broker for commission fees on policies the broker has sold over a period of time. The broker typically prefers payment by cheque with a detailed breakdown of payment for reconciliation purposes. With ISO 20022 payments, remittance data providing a breakdown can travel with the payment, which can be extracted to enable automated reconciliation when the payment is made.

A Life & Health insurer pays a claim to a health services provider through a Third-Party Administrator (TPA). The TPA processes and approves the claim submitted by the provider and sends a payment request to the insurer with remittance data detailing what the payment is for. By accepting the payment request, the insurer initiates a payment with remittance data pre-populated in the payment message which can travel with the payment to the TPA, and ultimately to the service provider.

An insurer disburses claims for multiple policies by submitting a bulk electronic payments file to their FI. Claims are paid directly to the insured, to beneficiaries (in the case of life insurance claims) or to intermediaries (brokers/agents). With ISO 20022 capability, each payment message can carry data on what the payment is for, including policy number, name of policyholder, payment recipient (if not the insured), the ultimate recipient and any adjustments.

An insurer sends electronic invoices with ISO 20022 request-to-pay functionality for monthly or annual premium payments due from those policyholders not set up for pre-authorized debit as they do not wish to share bank account info with the insurer. Payment links in the e-invoices enable policyholders to initiate payments from their bank accounts with data fields prepopulated with info about the payment (e.g., invoice number).

An insurer sends a payment request using ISO 20022 request-to-pay functionality to a policyholder when their monthly premium payment via direct debit fails to go through. The policyholder accepts by clicking on a payment initiation link in the message. A payment instruction is auto-populated with remittance data (e.g., policy number) provided by the insurer in the payment request message. Funds are immediately transferred from the policyholder to the insurer without the need to share bank account info.

An insurer receives a single payment from an insurance intermediary (e.g., broker or agent) for premiums they collected on behalf of the insurer over a period of time. The broker/agent deducts their commission fees and other adjustments from the payment. With ISO 20022-enabled payments, richer data can travel with the payment, which could be extracted and used to automatically allocate the payment across multiple invoices/accounts.