What to Expect from a Mobile Banking Solution? (Whitepaper)
0 likes524 views
Mobile banking involves using mobile devices to access financial services. A successful mobile banking solution requires selecting a software vendor to provide a platform that meets key principles: interoperability across devices and channels, security and privacy, flexibility and scalability. The platform functional view shows a unified communication module that interfaces between channels like SMS, apps, and the banking modules to process transactions securely after authenticating users and devices. The document also discusses ecosystem dependencies, popular services, and ensuring a comprehensive mobile device management system.
What to Expect from a Mobile Banking Solution? (Whitepaper)
- 1. T r u s t t h e E x p e r t s WHAT TO EXPECT FROM A MOBILE BANKING SOLUTION INTRODUCTION Mobile Banking (M-Banking) involves using mobile devices to gain access to financial services. A large number of mobile banking and payment solutions are available in the market catering to various needs of the financial institutions. The key to successful implementation is the selection of a software vendor who would be responsible for providing solutions to meet the organization’s requirement and to ensure the key principles of a good mobile banking solution.BASIC PRINCIPLES OF THE PLATFORM Interoperability Inclusive Implementation •Available to All • Delivered to All • Accessible by all Security and Privacy Openness Flexibility and Scalability Device Agnosticism WHITE PAPER
- 2. T r u s t t h e E x p e r t s FUNCTIONAL VIEW OF THE PLATFORM Legend: NFC: Near Field Communication, SMS: Short Messaging Service, USSD: GSM’s Unstructured Supplementary Services Data, IVR: Interactive Voice Response UNIFIED COMMUNICATION MODULE Unified Communication Module (UCM) acts as an interface between the various channels and the rest of the mobile banking platform. The UCM should communicate with the Telco’s service agents, clients, devices, applications and portals indicated at a* using the protocols supported by the various applications. UCM should be developed to also cater to any future message-format, channel or device. Future proofing is of paramount importance and the UCM should support at a bare minimum, the protocols at b*, The UCM should TGSLWP - WHITE PAPER 2 a*} SMSC: Short Message Service Center, SMS Aggregator, MMS: Multi Messaging Service, IVR Server, ATM, Micro ATM, Smart Client application and Mobile Web portal b*} SMPP: Short Message Peer to Peer, UCP: Universal Computer Protocol (a subset of which is EMI or External Machine Interface), HTTP: Hyper Text Transfer Protocol, HTTPS: HTTP Secure protocol, ISO 8583 and Web Services protocols such as SOAP: Simple Object Access Protocol and, REST: Representational State Transfer have minimum logic and should transfer the incoming message to the appropriate mobile banking module using a common interface protocol defined by the applications. After verifying the data, the UCM may interface with other modules for verification/authentication of the message before passing it on to the next module for further processing. Similarly all the outgoing messages need to pass through the UCM; with the UCM translating the message to the appropriate format before sending it to the mobile device. WHITE PAPER
- 3. TGSLWP - WHITE PAPER 3 INTEROPERABILITY IN SUPPORTED CHANNELS In supporting multiple channels it would be important to ensure the following: - • Support for Push SMS, Pull SMS, USSD, IVR, Mobile Web, Smart Client, SIM/WIB based application, NFC, Mobile as a POS, Outbound dialer (important in areas where voice confirmation may be preferred over SMS due to literacy issues), ATM and Mobile Point of Service (Mobile POS) • Seamless migration from one channel to another. • Need for just one-time registration by the user, irrespective of the channel used. • Ability of the channel management & communication module to recognize the transacting channel and respond appropriately SMS aggregation service is typically provided by the SMS Aggregator; hence banks will need to enter into a techno-commercial relationship with the SMS aggregator to get a short/long code and also to provide service to customers of all the telecom providers in the region/country. • The SMS based implementation is predominantly used for pushing the information to the individual user or business upon occurrence of certain events such as a purchase, funds-transfer or deposit. • Instead of opting for a short code (which works across all the Telcos), a bank may opt for a long code from a particular Telco. USSD service requires direct connectivity with the Telecom operator; hence banks need to have direct techno-commercial technical relationship with the Telco. SIM card based applications needs a relationship with the telecom operator. IVR & Outbound Dialer services could be implemented independent of telecom relationship. The service providers can provide and deploy a self managed solution at the Bank’s premises. IVR also provides the option of enabling solutions in local languages. AUTHENTICATION/SECURITY When it comes to authentication of the user and data security, the Platform: - • Needs to accept Static Passwords, One Time Passwords, Biometrics, usernames/passwords and additional profile questions depending on the type of activity • Should be able to accept the Mobile # or Device ID to authenticate the user • Should ensure authentication across multiple channels • Should be able to support HSM based AES, 3DES encryption, 1024 bit or higher PKI implementation (HSM: Hardware Security Module, aka Host Security Module, AES: Advanced Encryption Standard), 3DES: Triple Data Encryption Standard, PKI: Public Key Infrastructure • Should be able to store encrypted data with the ability to decrypt it after authentication • Should have adequate security features to securely store the data in the device T r u s t t h e E x p e r t s • Ability to configure & manage one or more channels for one or more services ECO-SYSTEM DEPENDENCY IN IMPLEMENTING CHANNELS In countries, with wide, reliable and affordable data connectivity, banks are recommended to use Smart Client or Mobile Web (WAP and HTML5) as the channel to implement mobile banking services without having to depend on the telecom operator. ECO-SYSTEM DEPENDENCY IN MOBILE DEVICES AND OPERATING SYSTEMS Internationally, there are a large number of mobile devices available. The features, functionality and operating systems being supported varies from device to device. Brand loyalty varies from country to country and within a country from region to region with a direct impact on the mobile banking system. Some of the popular devices are: Apple’s iPhone running iOS Samsung, Sony, LG, MTS and Motorola phones running the Android OS RIM phones running the Blackberry OS. Nokia phones running the Symbian OS Smart phones running the Windows mobile OS The solution needs to support the most popular device families in the country. In other words, the bank needs to make sure that their mobile banking application (smart client apps) as well as Mobile Web (invoked from the browser) are compatible with and are certified on the most widely used mobile devices. WHITE PAPER
- 4. TGSLWP - WHITE PAPER 4 In short the role of the MDM is extremely important in effective deployment of the mobile banking service to employees, businesses and marquee customers The MDM Platform needs to take care of the following scenarios at the bare minimum • Lost Device. • Unauthorized access to device or application. • Inappropriate use of the device or application. • Change in the employee/business/agency status (transfer, termination, change of responsibility within department etc). • Changes in the procedures and regulations. The high level system flow and role of MDM is shown below The features of MDM should be implemented to: - • Uniquely identify the device assigned to an employee, consumer or business. • Assign business functions and data access based on the delegation model. • Encrypt the information stored in the device even during transit. • Provide secure access to the application. • Remotely locate the device. • Identify abnormal use of the application. • Prevent use by unauthorized persons - by way of secure access, location control, usage control etc. • Remotely erase the data from the device in case of ‘lost device’ or inappropriate or suspicious usage of the device or application. • Remotely lock the application/device from any use. • Ensure a comprehensive anti-virus policy The conditions relating to data-access and data-modification will need to be implemented by the individual departments by providing appropriate Application Programme Interfaces (APIs), user level data-access controls and logging/auditing mechanisms. T r u s t t h e E x p e r t s MOBILE DEVICE MANAGEMENT (MDM) The MDM software secures monitors, manages and supports mobile devices deployed across mobile operators, service providers and enterprises. MDM functionality typically includes over-the-air distribution of applications, data and configuration settings for all types of mobile devices, including mobile phones, Smartphones, Tablet computers, ruggedized mobile computers, mobile printers, mobile POS devices, etc. This applies to both company-owned and employee-owned (BYOD) devices across the enterprise or mobile devices owned by consumers. By controlling and protecting the data and configuration settings for all mobile devices in the network, MDM can reduce support costs and business risks. The intent of MDM is to optimize the functionality and security of a mobile communications network while minimizing cost and downtime. Unified Communication Layer Transaction Management Security Management Check user credentials Device Management Check Device profile, user role, and permissions (location, time restrictions) WHITE PAPER
- 5. TGSLWP - WHITE PAPER 5 B2C (Retail Banking) • Informational Banking (mini statement, stop cheque, account balance, activity on account) • Payment – bill payment, P2P transfer (inter and intra bank) • Credit card payment, loading prepaid card with additional currency/funds • Time Deposit/Fixed Deposit facility on mobile • ATM Locator – GPS & Map integration • Branch Locator – GPS & Map Integration • Apply for Demand Draft/Traveler’s Cheque/Manager’s Cheque • Various Statement in PDF, SMS or other formats supported on mobile channels • In application / Out of application notifications or alerts SERVICES (Features and Functions) Disclaimer: All the documentation and other material contained herein is the property of Thinksoft Global Services and all intellectual property rights in and to the same are owned by Thinksoft Global Services. You shall not, unless previously authorized by Thinksoft Global Services in writing, copy, reproduce, market, license, lease or in any other way, dispose of, or utilize for profit, or exercise any ownership rights over the same. In no event, unless required by applicable law or agreed to in writing, shall Thinksoft Global Services, or any person be liable for any loss, expense or damage, of any type or nature arising out of the use of, or inability to use any material contained herein. Any such material is provided “as is”, without warranty of any type or nature, either express or implied. All names, logos are used for identification purposes only and are trademarks or registered trademarks of their respective companies. For more details visit, www.thinksoftglobal.com T r u s t t h e E x p e r t s PAYMENT SUPPORT The platform should integrate with core banking, the card management system and the prepaid system of the bank to enable all possible payment and banking options to customers. INTEGRATION SUPPORT The mobile banking platform should have a well defined integration layer for the platform to enroll more merchants (billers, over the counter merchants, other banking systems etc). The platform should have been developed using an open standard. A well defined Web Services API needs to be enabled for ease of integration and faster deployment. T r u s t t h e E x p e r t s FRAUD MANAGEMENT Detecting and preventing fraudulent activities is a key component of the mobile services platform. The platform should have the ability to integrate with existing fraud engines, define fraud rules, generate alerts and have the ability to either automatically block or provide the process for administrators to review and block any type of activity/users from transacting on the system. Detailed and summarized reporting of the suspicious activities, reporting of improvements due to implementation of various rules and the analysis of patterns based on various parameters are integral part of the fraud management module. Key features – • Fraud Prevention – Customer Education, Product Security (PIN, OTP, BIOMETRIC, Additional Factors – like profile questions, Device Characteristics mapping, M# verification) • Activity alerting – in-apps/out-of-apps (SMS / Call center call to verify activity) • Detection of Fraud – transaction (txn) pattern (value or # of txns, specific type of txn) - look for anomalous behavior • Resolution of Fraud– Customer Support, Channel Specific Fraud & fixing issues specific to channel, legal mechanism (zero-liability, breach of security due to s/w mal-function, inadequacies) USABILITY • Device specific rendering • Detection of device modes (portrait Vs landscape or vertical or horizontal mode), Touch Vs Non-touch device • Use of device features – for example use of GPS to locate ATM locator in the GPS enabled devices • Ability to inherit display characteristics of the device • Personalization to configure alerts/ notifications, configure service list • Support for QR code based activity • QR code on website or in the email, mailer indicating download URL for apps • QR code with bill information when scanned can pre-fill the bill payment information for the customer • Advanced Market Information • Allow Securities transactions B2B (Bank to other businesses) • Payment to businesses • Account Details • Approval – within bank or approval by businesses (including approval hierarchy support) WHITE PAPER