Anti-scam measures
Background
The Monetary Authority of Singapore (MAS) published a circular on Anti-scam measures in October 2024. The regulator has proposed and defined frameworks and guidelines on how to safeguard further financial transactions made on e-money payment accounts, issued by Major Payment Institution (MPI) licensees such as MatchMove.
Following the circular, MatchMove will gradually and continuously implement upgrades to bolster the security and safety of the platform.
As valued partners and consumers of our ecosystem, we prioritize your compliance and readiness for regulatory changes and a disruption-free experience for your customers. Preparing in advance for new regulations, it's imperative that you continuously enhance your applications and customer workflows to adhere to these regulatory guidelines.
Anti-scam preventive measures to be implemented in the Partner apps
1
Restriction on sending of clickable links or QR codes
A responsible financial institution should not send clickable links or QR codes via email or SMS to customers, unless they link to:
An informational website that asks for an access code
The webpage should not require the user to input their access code or one-time PIN (OTP) to complete a payment transaction
A platform to download and install applications
It can be a landing page to download the partner application or a universal link to an app store application.
No unwanted phone numbers
Phone numbers should not be added in the message unless the customer is expecting it.
Current MatchMove customer communications sent to customers:
- OTP sent via mobile for ECOM transactions that require a 3D Secure (3DS) authentication.
- Token activation request sent for cards to be tokenised on Google Pay or Apple Pay.
- Token lifecycle event sent for update of token statuses, which are tokenised by the end user.
Action Required:
As a platform user, you are urged to take an inventory of all the SMS and email communications that are currently being sent to your end users.
Ensuring that these messages adhere to the guidelines on using clickable links and QR codes in the message content.
2
Add additional metadata to outgoing transactions made in an account
To enhance transaction auditing and tracking, some additional metadata will need to be added to the transactions made in a user account. These additional metadata are the following:
Amount of the transaction
The amount transacted, whether credited or debited from the user account, should be displayed prominently and must be easily identifiable by the end user.
Details of the transaction
The payment details may include the transaction type, source of funds, comments, and notes on the transaction. Adding this data will help the end user and auditors identify and confirm transaction authenticity.
Action Required:
Prepare and add the following metadata to transaction API calls for audit and tracking. These additional metadata may also be used for the transaction notification content that will be sent to the customers later.
MatchMove API provides a way to add custom metadata to transactions initiated via the API. We can utilize the details field available in the fund transfer API, and use that to carry the custom metadata. The details field can accept a JSON string object with the following definition:
details.pp- Payment processor, which identifies which type of payment was processed or executeddetails.transaction_comments- Any message or internal comments on the transactiondetails.payment_ref- The payment reference identifier generated by the payment service providerdetails.source_account- The fund source account or card number for the debit or creditdetails.source_bank_name- The fund source bank name or the bank issuer of the card (when available)details.source_network_name- The name of the network where the transaction is processed, e.g., Mastercard, VISA, etc. (when available)
Various types of financial transactions can be made on the MatchMove platform. However, these are the credit and debit transaction types that we need to focus on:
Top-up done via debit card | DEBIT_CARD_TOPUP | — | Payment reference generated by the service provider | The masked card number of the debit card | The issuing bank name, when available | Card network name, when available |
Top-up done via credit card | CREDIT_CARD_TOPUP | — | Payment reference generated by the service provider | Masked card number of the credit card | The issuing bank name, when available | Card network name, when available |
Top-up done via internet banking | INTERNET_BANKING_TOPUP | — | Payment reference generated by the service provider | number of the source account | The name of the originating bank account | — |
Top-up done via cash over the counter | CASH_OVER_COUNTER_TOPUP | — | Payment reference generated by the cash over the counter agent | — | — | — |
A line of credit is given to the user | LINE_OF_CREDIT | — | Partner Reference ID from the LMS or internal reference number | — | — | — |
Working capital loan given to the user | WORKIN_CAPITAL_LOAN | — | Partner Reference ID from the LMS or internal reference number | — | — | — |
Generic credit | CREDIT | — | Partner Reference ID from the LMS or internal reference number | — | — | — |
Cashback is given to the user | CASHBACK | Human-readable comment that can be displayed to the user, enumerating details of the cashback | Partner reference ID for the transaction | — | — | — |
Load done by partner | PARTNER_CREDIT | Human-readable comment that can be displayed to the user, enumerating details of the credit done by the partner and its purpose | Partner reference ID for the transaction | — | — | — |
Cash / Credit note given by the partner in place of grievances | PARTNER_CREDIT_NOTE | Human-readable comment that can be displayed to the user, enumerating details of the credit note done by the partner and its purpose | Partner reference ID for the transaction | — | — | — |
Equivalent fiat top-up done for crypto loads | CRYPTO_REDEMPTION | — | Partner reference ID for the transaction | — | — | — |
Debit done for goods and services | MERCHANT_PAYMENT | Details of goods and services offered | Partner reference ID for the transaction | The merchant name for which the debit was initiated | The issuing bank name, when available | Card network name, when available |
Debit done for fees | FEES | The type of fee charged | Partner reference ID for the transaction | — | The issuing bank name, when available | Card network name, when available |
Debit done for other financial services | FINANCIAL_SERVICES_PAYMENT | Details of the financial service utilised | Partner reference ID for the transaction | — | The name of the originating bank account | — |
Debit done for crypto Purchase | CRYPTO_PURCHASE | Details of the purchase | Partner reference ID for the transaction | — | — | — |
3
Notify your customers regarding transaction activities in their accounts
You are required to deliver timely notifications to your end users on every outgoing transactional activity done in the system.
The table below highlights the list of recommended transaction notifications to the user, including the mapping of message content to the transaction details stored in the ledger.
Removal of funds | Push notification if available SMS or email | Type: MERCHANT_PAYMENT Successful merchant payment: <amt> to <details.merchant_name> on <time and date>. If unauthorised please reach out to <Partner hotline/support> immediately. Type: FEES Successful Fee deduction: <amt> for <details.transaction_comments> on <time and date>. If unauthorised, please reach out to <Partner hotline/support> immediately. Type: FINANCIAL_SERVICES_PAYMENT Successful deduction: <amt> for <details.transaction_comments> on <time and date>. If unauthorised, please reach out to <Partner hotline/support> immediately. Type: CRYPTO_PURCHASE Successful deduction: <amt> for <details.transaction_comments> on <time and date>. If unauthorised, please reach out to <Partner hotline/support> immediately. | On successful response of DELETE users/wallets/funds, trigger the notification to the end user |
P2P transfer initiated for the user within the platform | Push notification if available SMS or email | Successful transfer: <amt> to <recipient.email/recipient.sms> on <time and date>. If unauthorised, please reach out to <Partner hotline/support> immediately. | On successful response of POST users/wallets/funds, trigger notification to the end user |
Bank transfer initiated | Push notification if available SMS or email | Successful transfer: <amt> to <bank holder name>( <masked bank account number>) on <time and date>. If unauthorised, please reach out to <Partner hotline/support> immediately. | On successful response of POST /users/wallets/fund_transfers/credit, trigger notification to the end user Map the fields as:
|
Card transactions completed | Push notification if available SMS or email | Type: POS & ECOM transactions Successful Payment: <amt> to <merchant_name> using <last four digits of card number> on <time and date>. If unauthorised, please reach out to <Partner hotline/support> immediately. Type: ATM withdrawal Successful withdrawal: <amt> via <merchant_name> using <last four digits of card number> on <time and date>. If unauthorised, please reach out to <Partner hotline/support> immediately. | Subscribe to the webhook:
Upon receiving the webhook, process the payload message, then trigger a notification to the end user Map the fields as:
|
Remittance transactions completed | Push notification if available SMS or email | Successful remittance: <amt> to <account holder name>( <account number>) on <time and date>. If unauthorised, please reach out to <Partner hotline/support> immediately. | On success response of POST oauth/consumer/funds/transfers/overseas, trigger notification to end user |
*<Partner hotline/support> refers to the 24/7 partner support channels, made available to customers for incident reporting.
Action Required:
Notify your end users on any channel available for these types of transactions:
- A completed removal (debit) of funds from a customer account
- A completed P2P transfer between users or with the prefund
- Any bank transfers to and from bank accounts / mobile wallets
- A completed card transaction
- A submitted remittance transaction
For audit purposes, you are required to maintain logs that demonstrate the delivery and receipt of these notifications to end users. Along with the timestamps, the message content should also be included in the log. This log must be accessible, keeping a record of the last 12 months (this log period may be subject to change).
4
Alert customers before performing a high-risk activity
To safeguard users and ensure that they are adequately informed that they are about to perform a high-risk transaction. It is also vital that they are made aware of the associated risks attached to the transaction that they will be performing.
Identified high-risk activities
- Update of Personal Information, specifically:
- email
- mobile number
- address
2. Addition of new beneficiaries for:
- Cross-Border Payouts a) Mobile Wallets b) Banks c) Cash pickup to a new individual
- Domestic Payouts a) Addition of a new Bank Account as a beneficiary b) Addition of a new Mobile wallet as a beneficiary
Guidance for the alert message content
- Call out the activity by following alert activities as per the application UI scheme
- Call out a caution to the end user
- Have a clear explanation of the risks in the activity
- Give the user an immediate option to reject the action
- Explicitly request the user's consent before proceeding with the activity
5
Set up a 24/7 customer support channel
Partners are required to ensure that a 24/7 channel is available to customers, accessible at all times, for consumers to report unauthorized transactions.
Action Required:
Partners should have one or more of the following:
- Manned telephone line
- Dedicated phone number
- Messaging app channels, e.g., WhatsApp, Telegram
- Helpdesk portal for raising requests, digitally manned by a live agent
- Monitored email address
- Social media channels (if applicable)
In addition, the partner should have a Standard Operating Procedure (SOP) in place for addressing expedited resolution requests.
6
Self-service “kill-switch” feature
Aside from the available customer support channels, the partner must have an application feature that allows customers to temporarily suspend or disable their accounts ("kill-switch") on their own.
In conjunction with this, partners must also have a clear SOP for re-enabling or unsuspension of a customer account. Proper verification and authentication of the customer must be completed before the reenablement. This reenablement may be done through the administrator dashboard, Adminnet, or orchestrated using the API.
This “kill-switch" application feature should provide the customer with an immediate corrective action in cases where the customer suspects that a scam or fraud is in progress or has taken place.
Action Required:
Implement an application feature that allows:
- self-service account suspension or disablement
Set up an SOP for:
- customer verification and authentication before allowing
account unsuspension or re-enabling
Related Links
On this page
- Anti-scam measures