AI Augmented Mobile Banking Solutions
Project Developer	Keith Stewart
Project Owner	eSpherical.com, Inc, DBA GraphCube
Customer	Bangkok Bank — ธนาคารกรุงเทพ
Solutions Architect	Keith Stewart		GraphCube
Versioning	V 1.3
Document Library	REDACTED

The GraphCube software platform includes a comprehensive, secure, industry-leading mobile banking portal for Bangkok Bank. Our mobile portal provides the highest level of security available in the mobile industry as well as the most advanced mobile banking portal features available. The platform includes a collection of AI tools for managing customer identity, advanced threat detection, and analytical dashboards for greater business insight.

Our portal framework consists of a web front-end client processor which allows mobile access to any device and which provides easier access for customers and better customization for Bangkok Bank.

We provide a secure web-based mobile portal based on the Microsoft® .NET platform hosted within the Bangkok Bank existing secure data center. The advantages of our proposed mobile portal platform configuration include the following:

1. Advanced mobile technology; industry’s best in class.
2. Rapid and cost effective development and mobile deployment.
3. Available to all mobile devices.
4. Integrated Arcot® RiskForte™ digital authentication security software.
5. Integrated back-end mobile data triple DES data encryption.
6. Integrated cryptographic HASH for key data elements.
7. Simple and convenient interface for Bangkok Bank customers.
8. Integrated SMS/MMS notifications to customers and Bangkok Bank administrators.
9. Multiple language support (Thai, English, others as requested).
10. Fast and interactive mobile portal updates for Bangkok Bank administrators.
11. Scalable robust platform for future growth and enhancements.
12. Support from global software leader, Microsoft®, and industry leaders GraphCube and Arcot®.
13. Secure and integrated Identity Access Management (IAM) processes and algorithms for threat vector deterrence, authorized user management and access, account and/or client suspension/revocation and system audit requirements.

The Bangkok Bank mobile portal is be designed to enhance existing Bualuang iBanking features and functions to provide Bangkok Bank customers with seamless and efficient banking access via the mobile channel. A proposed top-level feature layout is shown in figure #1 below. Blue colored items are mobile portal pages, other colors represent back-end security checks, processes and transaction workflow management features.

Figure 1: Mobile Portal Layout

Using the .NET mobile platform for Bangkok Bank Mobile, custom content will be delivered to each customer based on the customer device mobile profile. This allows for a more rich experience for customers with Windows® Mobile, SmartPhone, BlackBerry®, iPhone®, and iPad® while also delivering complete content to customers with more standard-featured mobile devices. This dynamic content delivery is automatically processed via our .NET mobile software suite. This also allows for the seamless integration of new mobile devices that will become available to Bangkok Bank customers in the future. A sample mobile portal view for Bangkok Bank is shown in figure #2.

Figure 2: Sample Mobile Bangkok Bank Portal

The Bangkok Bank mobile home page will include key information links which are helpful for all customers as well as potential customers. These links will be integrated with Bangkok Bank’s existing online portal and include the following:

1. Bangkok Bank rates and Forex.
2. Bangkok Bank products and services.
3. Bangkok Bank ATM and branch location finder.
4. Bangkok Bank key contacts (direct dial from mobile portal).
5. About Bangkok Bank mobile portal.

The GraphCube mobile portal software will allow Bangkok Bank authorized IT staff to easily update the information on the home page links as needed and as products and services and locations are added and modified. This allows for efficient content and information management at the Bank level.

The mobile Account Access page is integrated with Bangkok Bank existing iBanking information and includes links to authorized customers' existing account information including the following:

1. View balances (savings, current, fixed-deposit, loan, and credit card).
2. View recent transactions. Track the movements of current, savings, and fixed-deposit accounts.
3. View credit card statements and transactions over the last three months.
4. View the repayment history of loan accounts to see remaining principal repaid transactions for the last twelve months.

The mobile Pay Bills page is integrated with Bangkok Bank existing iBanking information and includes the complete list of Bangkok Bank payees. Authorized customers can perform the following functions with the mobile Pay Bills page:

1. View a list of payees (including credit cards) and make payments.
2. Schedule payment dates for recurring bills.
3. View payment history for individual payees.

The mobile Funds Transfer page is integrated with Bangkok Bank existing iBanking information and includes a list of approved beneficiaries (Bangkok Bank and other local banks) as well International Banks (SWIFT codes, account information, etc.). Authorized customers can perform the following functions with the mobile Funds Transfer page:

1. Transfer funds between your Bangkok Bank accounts.
2. Transfer funds from your account to someone else’s Bangkok Bank account.
3. Transfer funds to accounts at other banks.
4. Instantly add 3rd parties accounts.
5. Send an SMS message to notify funds transfer recipients.
6. International Funds Transfer(*).
1. Transfer of expenses for education overseas.
2. Transfer of expats' savings working in Thailand.
3. Transfer of money to relatives or family with permanent residency in another country.

The mobile Mutual Funds page is integrated with Bangkok Bank existing iBanking information and allows authorized customers to invest in mutual funds by performing the following functions with the mobile Mutual Funds page:

1. Purchase, redeem or switch orders for mutual funds units.
2. Check the status of account holder mutual funds units.

The mobile Cheque Services page is integrated with Bangkok Bank existing iBanking information and allows authorized customers to perform the following:

1. Suspend your cheque payments.
2. View the list of cheques issued that have been returned over the last two months.
3. View the list of cheques deposited into your accounts that have been returned over the past two months.

The mobile Promotions page allows authorized Bangkok Bank administrators to add and edit strategic bank promotions through an easy-to-use administrative web portal. The GraphCube mobile banking software can also integrate with Bangkok Banks existing online promotions, Whats New, and deliver these promotions to mobile customers. These promotions can be made available exclusively to the mobile channel if desired. Promotions can be tailored to specific customers, both registered logged in customers and general customers browsing the mobile portal. Promotions could include the following popular items:

1. Rewards offered to preferred selected bank mobile customers.
2. e-Voucher discounts for mobile-channel customers from preferred local vendors (dining, insurance, movies, airlines etc.)
3. Privileges to preferred mobile customers.
4. New offers specially targeted to mobile banking customers only (example: special flight promotions on Thai Airways or Nok air when using the Be 1^st Credit Card).

The mobile My Settings page allows authorized customers to modify some of their information including contact and email details as well as set their SMS notification preferences. SMS notifications can be set for bill due dates, account balance warnings, transfer status, and other items. The My Settings page also provides help menus for customers to get additional help about each of the specific mobile features.

The following chapters of this document include technical details about the GraphCube mobile banking software as well as our proposed system architecture, security, and ongoing support and enhancement services.

GraphCube recommends a leading-edge secure and comprehensive mobile banking portal and software suite for Bangkok Bank. Our recommended model includes key processes and design details to ensure a successful mobile banking portal for Bangkok Bank. Key details include the following:

1. Deployment of an advanced secure .NET customizable web front end mobile portal.
2. Integration with Arcot Corporation RiskForte™ digital authentication software.
3. Integration with VeriSign® 128-bit SSL digital server certificates.
4. Integration with Microsoft® Windows servers and SQL Server® mobile databases.
5. Deployment of triple DES data encryption in SQL Server® for selected mobile data.
6. System Independent Verification and Validation (IVV) audit by 3rd party security firm (Disys Corporation) prior to deployment.

The following sections of this proposal provide technical details about our mobile banking portal for Bangkok Bank.

The mobile banking module can be thought of in terms of three primary Functional Areas where the software performs a series of Functional Processes based on a given set of business rules. The functional areas include:

1. Customer Area (mobile devices and server connections).
2. Service Broker Area (mobile transaction processor; Bangkok Bank).
3. Financial Institution Area (Bangkok Bank server).

There are five primary Functional Processes which the mobile banking module performs. These functional processes include:

1. Customer Login Process.
2. Customer Validation & Authentication Process.
3. Presentation of Transaction to Customer.
4. Transaction Processing and Authenticity Verification.
5. Transaction Acceptance, Completion and Audit Creation.

Each functional area is integrated through a series of secure connections to permit a secure login and transaction process. Figure #3 below is a general diagram of these functional areas. Detailed explanations are included in the following sections.

Figure 3: Mobile Banking Software Web Service Functional Areas

In reference to Figure #3 , the Functional Areas and Processes for the mobile banking software are described in accordance with the corresponding numbers in the figure.

1 This functional area represents the Customer Area or the main entry point for mobile users. The customer functional area refers to any mobile connection and/or wireless device connecting via the Internet. These mobile users connect to the Bangkok Bank mobile transaction server and initiate login. The mobile banking transaction server detects each connected mobile device and then delivers the most appropriate configuration for the device. There can be unlimited mobile users on the transaction server; in the event processor resources are completely consumed by overwhelming numbers of users, users are managed with load-balancing software that preserves session binding variables. Note: Session variables are encrypted by the transaction server and then bound to the connected mobile device.

2 This functional area represents the Service Broker or mobile transaction server. The Service Broker performs a critical role as the primary transaction processor/server as well as the primary security interface protecting and shielding the connected financial institution from potential security threats. Specifically, the service broker manages the following security parameters:

Figure #4 is a diagram of the standard technical processes required for mobile transactions. Each of these steps is described in detail in the following sections.

Figure 4: Mobile Banking Software Web Service Functional Processes

The first step of the mobile transaction process involves the customer login. Customer login occurs on the transaction server via a login page formatted for the connected mobile device. The login process includes a series of security filters and security checks; these checks and filters are designed to ensure the integrity of the connected device and to validate the origin of the login process. Specifically, the following parameters are validated on the connected customer and validated with the transaction server credentials:

1. Customer Origin: the referring page from which the customer has requested the login. This security check ensures that the login request is from the Bangkok Bank transaction server. No other origin is allowed; the login is terminated if the customer origin not via the transaction server page. This prevents page hijacking or spoofing.
2. Customer Session Variable: the transaction server checks the connected customer for an encrypted session variable from the transaction server. If this session variable is not present or has been corrupted, the login is terminated. This session variable check prevents page hijacking or spoofing.

A If the above security filters and checks are successfully validated, the connected customer (mobile device) is presented with the Bank login page. The login page is presented only over an SSL connection. In the event an SSL connection is not made, the client is automatically redirected to port 443 for a secure connection. The customer is also presented with a Locked Icon with the words Secure if the connection is secure. If the connection is NOT secure, the Lock Icon is open and the warning Not Secure — Stop is shown to the customer and the login button is disabled. This lock is also bound to the transaction server IP. If a secure connection cannot be established, the login process is terminated.

If all the security filters and checks for Step 1 are met, the customer login page is sent by the transaction server via an encrypted https Post method to the Bank security stack.

The second step of the mobile transaction process involves three primary phases.

1. Phase 1: transaction verification (security stack interface).
2. Phase 2: customer validation and authentication (Bank server) via Arcot® Risk-Forte™ authentication software.
3. Phase 3: customer authentication results pass-back to the transaction server

Phase 1 starts at the Security Stack Bank interface. The Security Stack includes the following layers and functions which serve as security filters and checks before any transaction is allowed to pass through the Bank firewall.

1. Port 443 Filtering: the first security stack layer includes a filter for checking to ensure that the transaction from Step 1 has been directed to port 443 (SSL) at the Bank interface. This filter is shown in Figure #4 as the green server port. If the login transaction is NOT presented to port 443, the login is terminated and sent back to the transaction server.
2. IP Lock: the second security stack layer includes a filter to check the IP address of the referring server for the login page. The IP Lock layer will only accept requests from the transaction server IP. Any other IP addresses are blocked and transaction processing stopped.
3. Session Lock: the third security stack layer includes a filter to check for the existence of an encrypted transaction server session variable. This session variable is required for the transaction and can only be set by the transaction server. If a transaction session variable is not present, the transaction processing is stopped.
4. Server Lock: the fourth security stack layer includes a server shared key and predefined session variable. This shared key/session variable can only be set and read by the transaction server and bank server. If a shared key/session variable is not present, transaction processing is stopped.
5. Bank Firewall: the final security stack layer consists of the Bank Firewall. The Bank firewall is controlled and managed by the Bank in accordance with their rules and procedures.

In order for a login to be presented to the Bank for validation and authentication, each of the above security layers must be successfully passed in accordance with predefined rules. These predefined rules are established in a written Service Agreement between the Bank and the technology vendor (GraphCube). If the transaction fails to successfully pass any of the above security layers, transaction processing is stopped and the transaction event is logged in a failed transactions table in the mobile transaction server database.

Phase 2 takes place on the Bank server and includes customer login validation and authentication. Phase 2 is a Bank process and occurs in accordance with Bank rules and regulations. The service broker is not directly involved in the Bank customer validation and authentication process except to ensure that all security layers are successfully passed at the security stack before a customer is presented to the Bank for validation and authentication.

At this phase of customer authentication, the mobile banking software invokes the Arcot® RiskForte™ authentication software according to the figure #5.

Figure 5: RiskForte™ Customer Authentication

The RiskForte™ process is designed to create a real-time risk assessment profile and then determine the action allowed based on Bangkok Bank’s predefined business rules. Specifically, every transaction generates a risk score which is then evaluated against the bank business rules and the appropriate action is then processed (Approve transaction, Decline transaction, Alert Customer Service Representative-CSR and provide additional authentication). A summarized explanation of the process is provided as follows:

1. Customer location ID, device ID (mobile IMEI number) and user ID is evaluated based on user login history and device identification.
2. User transaction type and details are compared with historical transaction data for this user (Risk Model) and evaluated with the parameters collected in (1) above. A Risk Assessment score is generated for this user and this transaction.
3. The risk score is compared with Bangkok Bank business rules (policies and user details) and a decision is generated based on the risk score and business rules.
4. The decision generated in (3) authenticates the user transaction in one of three decision matrices:
   1. Approve the transaction based on the risk score and business rules
   2. Alert the customer service representative (CSR) and require additional authentication information from the user (security questions, etc.)
   3. Decline the transaction based on the risk score and business rules and create an audit trail.

The above RiskForte™ process is seamless and transparent to the customer and occurs in real-time during the transaction processes.

Phase 3 involves the Bank-to-Transaction Server pass-back for the following security parameters:

1. Authentication status.
2. Customer login status.
3. Transaction status.

This process includes an XML SOAP data package (Web Service) post to the transaction server. The SOAP data package contents are based on the authentication status (authenticated or not-authenticated) for the customer login. Examples of standard SOAP data package elements and structure are included in Figure #6 below. An explanation of each data element is included in Table #1 below Figure #6.

Figure 6: Authenticated User SOAP Web Service

For the above authenticated user SOAP data package, each of the data elements are described in further detail as follows:

Table 1: SOAP Data Elements Description

Data Element	Description	Required
AuthenticationStatus	Controls if a user is authenticated or not. The only possible values are: 1=authenticated and 0=Not authenticated.	yes
TraceID	Unique value set by the transaction server used to uniquely determine each transaction and to manage transaction state. This element is used for tracking of transactions.	yes
BankID	Preset value between the Bank and the Technology Vendor. The Bank ID uniquely identifies each individual bank. This could be the Bank SWIFT code or other code for reference.	yes
BankName	Name of the Bank. In this case Bangkok Bank was used.	yes
ServerKey	Session variable or key which uniquely identifies the transaction server. This element is described in Figures #6 and #7.	yes
VendorKey	Session variable or key which uniquely identifies the Technology Vendor.	yes
IPKey	Session variable or key which uniquely identifies the IP of the transaction server request.	yes
CustomerSession	Session variable which is established between the Transaction Server and the connected customer (mobile device). This is a unique session variable which identifies a connected mobile client.	yes
ExtraKey	Reserved for future use. It could include other security keys established by the Bank or Technology Vendor.	no
Transaction	Parent XML element for the Transaction details node. It is an XML structural element only and takes no value.	yes
TransactionNumber	Unique transaction number set by the Bank for each individual transaction.	yes
ClientReference	Unique Client reference (transaction) number which is set by the Client. This could be a reference to a bill being paid.	yes
CustomerFname	Authenticated customer’s first name. This name is set by the Bank.	no
CustomerLname	Authenticated customer’s last name. This name is set by the Bank.	no
GMToffset	Greenwich Mean Time offset for the Bank country and location. This is set by the Bank. In this case, a GMT offset of 7 hours is set for Thailand. This allows for the correct transaction date and time to be set.	yes
EffectiveDate	Effective date of the transaction. This is by default set to the current date.	yes
EffectiveTime	Effective time of the transaction. This is by default set to the current time.	yes
CurrencyType	Default currency for the transaction. In this case, the currency is set to THB (Thai Baht).	yes
TransactionAmount	Charge amount for the transaction. This value is set by the client or payee. For this case, the amount of 12609.00 THB was set. The transaction amount value must be in the currency as specified in the CurrencyType element.	yes
TransactionFee	Amount of the fee associated with the transaction. If there is no fee, the value is set to 0. This fee is determined by the Bank.	yes
CustomerAccounts	Parent XML element for the Customer Accounts details child node under the Transaction parent node. It is an XML structural element only and takes no value.	yes
AccountType	Customer account type. The possible values include: 1=current (checking), 2=savings, 3=fixed deposit, 4=joint, 5=other. This value is set by the Bank.	yes
AccountNumber	Account number associated with each AccountType element. This value is set by the Bank.	yes
PaymentStatus	Status of the payment process. The value is set by the Bank. Possible values are: 0=payment not accepted/pending and 1=payment accepted. The default value is 0.	yes
BankReference	Reference value set by the Bank. This can include any payment reference number which the Bank wishes to use.	no

In the event a customer is not authenticated, the Bank will return the following SOAP data package (figure #7) to the transaction server.

Figure 7: Non-Authenticated User SOAP Web Service

The SOAP package detailed in figure #7 includes the Authentication Status value of 0, which means that the customer login was unsuccessful. Based on predefined business rules, the non-authenticated customer may be allowed several more attempts to login. If this is the case, the transaction server will allow the customer to reenter their user ID and password. It is the policy of GraphCube to allow no more than three (3) consecutive login attempts by a customer. After the third unsuccessful login attempt, the customer is prevented from any further login. This process can be modified based on the Bank requirements. This policy is further described in the section titled Software Operational Written Agreements.

The GraphCube mobile banking software is written in Microsoft® .NET and runs on Windows™ web servers. The enterprise database is Microsoft® SQL Server and the server digital certificate is a 128-bit VeriSign® server certificate. Figure #8 shows the generalized architecture for our mobile transaction system.

Figure 8: Hardware Architecture Diagram

In Figure #8, the existing mobile transaction system architecture consists of four primary application servers, each with a particular function. External to the system architecture are connected mobile devices, displayed in the diagram for reference. For the purposes of this technical proposal, the primary consideration involves the Transaction Server to Bank Processing Server interface connection. For reference, the four server components and connected mobile devices are detailed below:

Bangkok Bank Transaction Server: This server manages all mobile device connections and also communicates with the Bangkok Bank corporate server. The transaction server also is connected to an SQL server database for managing mobile transactions. The transaction server and SQL database are protected by firewalls and managed port scanning and monitoring. The transaction server includes a 128-bit VeriSign® server certificate for SSL connections.

Bangkok Bank Mobile Development Server: This server includes a development platform for the mobile banking software. Keeping the development environment inside the bank ensures a more comprehensive security matrix. The development server is protected by a firewall, IP restriction rules, and VPN connections.

Bangkok Bank Corporate Server: This server contains Bangkok Bank customer information. Interaction with this server is via only trusted transaction server connections. The bank corporate server is protected by firewalls and other bank specific security parameters.

Disaster Recovery Server: GraphCube proposes a mobile disaster recovery server for Bangkok Bank to ensure continuity of operations in the event of a production server failure. The disaster recovery server should be continuously updated with current data.

SQL Database Server: The SQL Server database resides on a separate database server for security and performance. The SQL Server is protected by firewalls and other security restrictions.

Connected Mobile Devices: This is not a server environment but rather a framework where mobile customers connect to the bank transaction server. The transaction server manages these connections through shared session bindings and delivers content to the connected devices as well as device transaction processing and generation of risk scores according to the RiskForte™ authentication software. Connected mobile devices are managed via session variables and SSL 128-bit secure connections.