Payment Fraud Solution System

1 This document and all of its content is property of TBC BANK, JSC. The information in this document is confidential and should not

be disclosed to any other person. It may not be reproduced in whole, or in part, nor may any of the information contained therein be

disclosed without the prior consent of TBC BANK.

Payment Fraud Solution System Request for Proposal (RFP)




Purpose

In order to transform the fraud management capabilities, improve defense against fraudulent

activities and fraud prevention/detection rate, TBC Bank intends to implement sophisticated fraud

management solution. The fraud identification and loss prevention should be balanced against the

quality of customer service experience.

The purpose of the purchase and installation of the system are but not only:

1. Reduce payment fraud losses (including plastic card and distance service/digital

operations, Wallet operations) to acceptable risk level (Acceptable risk level should

not exceed pre-defined fraud rates per SCA regulation)

2. Improve banks efficiency to detect fraud through customer behavior model analysis

ensuring low false positive rate

3. Enabling bank to perform risk-based real time analysis of transactions and

distance service/digital activities to ensure instant fraud prevention

4. Enable bank to deploy machine-learning models to respond instantly to new fraud

schemes and constantly improve model learning capabilities

5. Enable bank to gain access to worldwide fraud scenarios and fraud schemes to

enable forward-looking anti-fraud systems

6. Ensure banks’ Compliance with strong customer authentication (SCA) regulation

requirements

7. Enable bank to deploy various risk management and SCA method strategies based

on transaction risk score to ensure superior client experience

Scope

The anti-fraud solution should cover following areas:

8. TBC bank’s clients debit or credit cards (POS, ATM and e-commerce operations)

operations/transactions (from the moment of transaction authorization request )

9. TBC bank’s clients operations/transactions via Wallets (adding cards to various

wallets, as well as performing operations/transactions via wallet)

10. All operations within TBC Banks’s merchants (merchants where TBC is acquirer

Bank) including E-commerce and POS operations (from the moment of transaction

authorization request)

11. Unauthorized transactions from fraudulent merchants on TBC bank clients’

accounts (Where merchant performs financial operation on TBC bank’s client’s card

without prior authorization from the bank’s processing center)




12. Distance service transactions/operations performed via internet banking/mobile

banking or other TBC bank applications such as Space, TBC Credit web-portal, TBC

mortgage platform and open-app services etc.

13. Distance service suspicious activities performed via internet banking/mobile

banking or other TBC bank applications such as Space, TBC Credit web-portal, TBC

mortgage platform and open-app services etc. such as logging to application,

change application credentials etc.

Requirements and deliverables

# Requirement Detailed Definition

1. Real-Time behavioral

Analytics

In result of the analysis of customer behavior, the Strong Customer

Authentication regulation requirements must be met.

The system should be able to analyze at least 6 months period of

clients behavior

During the real time analysis, if anomalies are found that differ from

the client's usual behavior, there should be appropriate decision rules

in order to automatically send the relevant authentication request (3D

secure, OTP, biometric authentication, etc.) to the client.

Customer behavior advanced analytics should take into account

applicable risk-based factors such as follows but not limited to:

abnormal transaction amount/quantity, abnormal/new transaction

recipient, abnormal geo location patterns (for instance adding card to

wallet from different country, or logging to Ibank/Mobile from

new/unknown IP address/or Device), abnormal channel activity

(different from customer’s normal behavior); abnormal

spending/payment pattern, which is different from standard spending

patterns of individual (including transaction volume, quantity,

merchants and other characteristics of the operation); performing

operations (including logging to distance service applications/adding

cards to wallets) from abnormal Customer’s Device ID or IP addresses;

Track transaction details including transaction Codes, Point Codes,

MTI, MCC, RC, DEV_TYPE etc. tracking abnormal non-transactional

distance/digital activities such as logging to applications, changing

client logging credential or personal data information (including Mobile

number, e-mail address etc).




2. Real-Time fraud

monitoring

requirements

1. For credit card and debit card operations fraud behavioral

analytics should be performed at the moment of transaction

authorization

2. For distance service operation (i-banking, mobile-banking etc.)

fraud monitoring should be performed at logging and through

active client session, including transaction initiation moment

3. Merchant Monitoring should be performed at merchant

transaction authorization moment

4. Wallet Operations should be monitored at the moment of

adding cards to wallet, also every subsequent wallet

transaction authorization should be monitored

3. Merchant Risk

Analytics

Transaction and fraud data assessment in real time to identify

fraudulent behavior and provide recommended actions in terms of

issuing and acquiring as well. Applicable decisions should be provided

for all merchants including non- 3D merchants.

Merchant Profiling should take into account factors as and not only:

merchant transaction history, amount of the transactions for each

merchant in a specific period of time (day, week, month, etc.), volume of

transactions, merchant geo locations (white/black listed countries),

acquirer location; BIN; IP addresses; recurring transactions, volume of

transactions for each customer; declined transactions for each

merchant.

The system should be able to limit the amount of merchant

transactions by various criteria: Maximum amount of transactions

allowed with one card per day /week/month; Maximum amount of

transactions allowed per day/week/ month; etc.

4. Machine Learning

Model

The system should be able to instantly respond to new fraud schemes,

including analysis of banks actual fraudulent operations to improve

fraud prevention mechanism.

The system should be able to constantly improve learning capabilities

based on new fraud schemes.

5. Access to world-

famous/widespread

fraud patterns

The system should incorporate information of worldwide fraud

schemes and trends to include those patterns in anti-fraud model and

enable bank to perform forward looking risk management

6. Risk Rule

Management

Except of behavioral model system should enable to add custom risk

management rules

The rule modification process should be flexible, instant and performed

without IT development or intervention




The system should enable complex rules patterns (rule which is based

on multiple variables)

7. Fraud Case

Management

If suspicious operation is detected, the system should be able to send

notification to client regarding such operations. Following alarm

channels should enabled (e-mail notification, SMS or mobile-call).

The system should also enable functionality to record client feedback

on suspicious activity notification, to measure false positive rate (self-

reporting function in case of SMS and e-mail notification), manual

reporting via mobile call option)

The system should also have functionality to declare fraud cases which

were not detected by the system. Such fraud cases should be analyzed

by the system to improve anti-fraud model.

8. Charge-Bank

Management

The system should enable functionality to record charge-bank status

(charge-back request and charge-back results)

9 Other Functionality

Requirements

The system should enable fraud model effectiveness analysis and

custom risk rule analytics (fraud detection per rule etc.)

The system should store logs of every rules or model logic changes

The system should provide the virtual send-box for simulation

modeling on the production

The system should enable tracking of each operation risk scores

and provide detailed information regarding factors which

contributed to transaction decline due to fraud suspicion

The transaction/operation search functionality based on various

parameters such as (Account number, amount, date, Risk Score,

Auth. type, Status etc.)

Functionality to import frauds reports for VISA/MC fraud database

(optional/value adding function)

Functionality to update/import BINs of VISA/MC on daily basis

(optional/value adding function)

Functionality to update MCC code, Country code, currency

Easy and intuitive user management experience for Bank’s Staff

10 Integrations The system should be integrated to UFC processing, ACS

The system should be integrated to TBC application e-banking, mobile-

banking, Space and other platforms (bank’s SCA code generation

centralized engine)

11 SCA authentication

functionality

The system should determine most effective strategy for SCA and send

respective request to bank centralized engine (SCA strategy can be as

follows but not limited to: send SMS code to client, call client, Video

verification etc)




12 Reporting

Requirements

The System should enable comprehensive fraud reporting capabilities,

which should enable standard best practice reports, however the

system should have high flexibility to generate ad-hoc customized

reports.

Examples of some basic risk required risk reports are presented

below:

Fraud Detection Rate Statistics (per channel, per SCA rules and

other sub-categorization

Merchant fraud statistics

Model Efficiency and Custom Risk Rule effectiveness Rate

False positive Rate

Trend of declined transaction

List of applied model rules and custom risk rules

Fraud loss amount

Charge bank report (number/volume of charge-back operations

and charge-back reimbursement rates)

Unauthorized transaction statistics (volume, frequency, merchants’

level etc.)

13 System KPIs: Fraud Detection Rate:

The fraud management solution must be accurate enough to ensure

that risk level isn’t higher than the reference fraud rate.

The overall fraud rate for each type of transaction shall be calculated

as the total value of unauthorized or fraudulent remote transactions,

whether the funds have been recovered or not, divided by the total value

of all remote transactions for the same type of transactions, whether

authenticated with the application of strong customer authentication or

executed on a rolling at least quarterly basis (90 days).

Exemption Threshold

Value (ETV)

Remote electronic

card-based

payments

Remote electronic

credit transfers

500 GEL 0.01 % 0.005 %

250 GEL 0.06% 0.01%

100 GEL 0.13% 0.015%

False/Positive Rate: (Desirable - 25% MAX)

Decision Timing-Score Calculation (Desirable - 50ms – 60ms)

System throughput – (Desirable - MIN 1000 TPS)

Performance scalability based on business demand




INFORMATION TO BE PROVIDED:

- General information (according to Annex 1)

- Price and delivery schedule (according to Annex 2)

- Information on similar services (according to Annex 3)

- IT Infrastructure Requirements (according to Annex 4)

- Baseline Security Requirements (according to Annex 5)

- Service terms and conditions

PROPOSAL SUBMISSION AND EVALUATION:

Participant Company shall submit all above listed documents (signed and stamped by an

authorized representative) in electronic procurement system www.etenders.ge. Bidding will be

held in the so-called One Envelope Principle (http://etenders.ge/Page/Instructions)

DEADLINE FOR PROPOSAL SUBMISSION: 22.02.21; 17:00 HRS. (UTC/GMT +4 HOURS)

- Contract will be awarded and agreement will be signed with the organization, which provides

proposal according to following criteria:

Experience References and Success Stories; Experience on Similar

Projects; access to global payment fraud data base

Value/Pricing Structure and Price Levels Implementation Price; Maintenance Cost;

Manday rate

Suitability of the Proposal Functionality; Fraud reduction rate; Customizable; User

friendly; implementation time

Technology AI (artificial intelligence); Cyber security

requirements

- Price should be indicated excluding VAT, in any currency;

- In case of demand of advanced payment, Bank may require a bank guarantee for the

amount demanded in advance, as well as if applicable, the act of comparison issued by the

revenue service, in which debt should not be reflected.

- Well-founded complaint can be submitted by the supplier within 3 days. This time is

calculated from the date of delivery of the information to the supplier to which the claim relates.

http://www.etenders.ge/

http://etenders.ge/Page/Instructions




- Tender can be terminated by the bank, in the case of proper reasons existence, on which

will be informed all participants; Bank also reserves the right to recognize the tender voided in

case of participation of single company.

- Any other conditions imposed upon the buyer and executor shall be considered in the

service agreement.

CONTACT DETAILS

For any questions/consultations needed during RFP preparation, evaluation and submission

process, please do not hesitate to contact:

Name Position Phone Number E-mail

Tamari Maisuradze Procurement Manager +995 595 99 60 62 [email protected]

Tamari Ujmajuridze Procurement Manager +995 558 14 44 42 [email protected]

mailto:[email protected]

mailto:[email protected]




Annex N1

General Information:

A legal form and full name of the bidder:

Identification Code:

Position, name and surname of the contact person:

Email, Telephone:

Service bank:

SWIFT code:

Acc. number:

1. Total price of the tender proposal:

2. Payment term:

3. Service Delivery Time:

Signature of the bidder ________________________________

(Stamp)




Annex N2

PRICE AND DELIVERY SCHEDULE

Information has to be submitted in compliance with the below tables:

N Name of the service Price Comment/any other

costs

Delivery time

1 Implementation Price

2 Maintenance Cost (1 year)

3 Man-day rate

Total cost:

Please provide the price for support of 3 options:

1 Support fee for 3 years




(Stamp)




Annex N3

INFORMATION ON SIMILAR SERVICES

Information of the services executed over the past 2 years or at the moment

Note: Requested information must be presented in detail

Bank reserves the right to verify the information


(Stamp)

№ Name of Service Name of purchaser Period Comment

1

2

3

4

5

6

. .




Annex N4

IT Infrastructure Requirements

Solution logical and physical diagram

Hardware Platform: Based on modern technologies

x86 architecture compatible hardware

VMware Hypervisor support

Modern container platforms (K8s, Docker)

Ability to deploy on “cloud computing services” (AWS, Azure ,GCP)

Hardware Requirements: Number Of Cores Required

RAM Required

Disk Requirements: Disk Space Required

Average disk Read/Write operation required

Disk throughput Read/Write

Network Requirements: Network Bandwidth 100MB 1G 10G

Access to internet

Access from internet

Access to partners (VPN)

Application Platform Requirements: JBOSS EE

IIS 10

IBM WebSphere

.Net Core (Provide version)

Other (Please provide Name\Vendor\Version)

Server OS Requirements: Windows 2019

RedHat ES 7.x OR 8.x


DB Server Requirements: Microsoft SQL 201x (Edition)


Availability: Reliable architecture

Scale-out system architecture

Horizontal scalable architecture

Fault tolerate configuration/mechanism




24/7 Availability should be supported during system components version

upgrades

Network Load Balancing Support

Monitoring: Advanced System Health Monitoring tools

Advanced Log management and error reporting tools

Client Side Requirements: Windows 10 x32

IE 11 Support

Edge Browser Support (Chromium)

Google chrome latest’s version

RDS Side Requirements (Branches) Support MS Terminal Servers – Based on 2008 R2 and Server 2019

Protocol RDP

Thin Clients Support – Windows 10 embedded, Windows 10 IOT, Windows 7

embedded, eLux RP 4.0.1-2

Desktop support – Windows 7 Enterprise, Windows 10 Enterprise

Integrations Ability to integrate with other systems using REST(preferred) or SOAP protocol

At least two API version backward compatibility support is desirable

Integration with existing systems involved in the process is required

System should have ability to export data for external systems in order to make

offline reporting and analysis using DW tools

Integration with RTPS, TIETO

Information required for deployment

Database Server Requirements: Supported OS

Supported Database (include edition)

RAM

CPU (Cores)

Network

Disk Space



App Server Requirements: Supported OS

Supported Platform (include edition)

Other (Components)

RAM

CPU (Cores)

Network

Disk Space






Web Server Requirements: Supported OS

Supported Platform (include edition)

Other (Components)

RAM Required

CPU (Cores)

Network

Disk Space

Client side Requirements: Supported OS

Supported Browser

Other (Components)

RAM Required

CPU (Cores)

Network

Disk Space




Annex N5

Baseline Security Requirements

Please, fill annex below if applicable

1. System Development and Acquisition process

Topic Requirements Status Comments

Follow

ed

Not

Followed N/A

DEV-01

The development and maintenance process

should be based on exchange means that secure

the confidentiality and integrity of exchanges

with the bank (requests for change, code

exchanges, versioning, patch management, etc.).

Exchange of Confidential and Internal

information with the third party should only be

made Using the system Controlled by TBC Bank

DEV-02 A prior conformity check of the code should be

done to make sure that:

The program only performs the

functions for which it was developed

(access to resources, processes)

There is no vulnerability likely to give

rise to any illicit modification or

embezzlement of its functions.

DEV-3 The system should not contain any malware or

fraudulent software according to the state of the

art (software without valid license, viruses,

Trojan horses, logic bombs, key logger, etc.).

DEV-4 During the lifecycle of the system at Least

Following Environments should be present:

- Development

- Test/UAT

- Production

DEV-5 The System Should be free from any obsolete

components that can no longer be technically

maintained and that are no longer included in

editor or community support.

DEV-6 No Administrative Privileges should be required

to start the Application




DEV-7 Any application put on Production does not

contain any test or debug-type information.

DEV-8 The application and the elements it implements

operate on the basis of the “principle of least

privilege” so that no process works with more

than the minimum rights necessary for its task.

DEV-9 The functions and services are executed in an

autonomous and secure manner to avoid any use

of an element common to several applications.

DEV-10 The arrangement of the functions should not

permit any capacity overrun (buffer overflow)

which could enable malicious use (code

execution).

2. Architecture and Configuration


Follow

ed

Not

Followed N/A

CON-02 Each layer should be logically separated

Communication between layers should be

authorized

CON-03 Sensitive Configuration information should be

encrypted (Connection strings, passwords for

accessing DB, etc.)

CON-04 Existing documentation must fully cover:

Configuration guide

Logical/Technical architecture

Functional architecture/description

Implementation Checklist/Guide

CON-05 System design must have backup functionality

for critical services and functions and must

follow approved backup procedure.

3. Application Security


Follow

ed

Not

Followed N/A

APP-01 Password should be stored using non-

compromised strong Hashing Algorithms

APP-02 No transaction must be partly managed. When a

transactional process is divided into several

steps, each one must be accepted to validate the

transaction. In the event of an error, the entire

transaction must be quit and the system must

return to its initial state.




APP-03 Web application development principles comply

with the secure development guides of the

OWASP.

APP-04 Personal or sensitive data, including those

related to authentication, must never be

submitted to the server via the GET method. The

POST method must be used for this purpose.

APP-05 HTTPS should be used in order to exchange

authentication and other sensitive data between

the system components and other systems

APP-04 The URLs must be compliant with the RFC2396.

APP-05 The total length of an URL + HTTP headers +

parameters and arguments must not exceed 8Kb

APP-06 All parameters and arguments must be typed

and limited in size (int, char, string, etc.),

particularly character strings.

APP-07 The URLs must not contain the following

characters or sequences of characters (in native

or escape format, or in combination):

characters less than 0x20 and greater

than 0x7E

back slash (ASCII code 0x5C); back quote

(ASCII code 0x60);

The sequence /.; the sequence /..;

APP-08 Prior to processing or storing to database all

Input data should be validated. Validation should

be performed on all levels

At least following validation should be

performed:

- Permitted Size or length

- Permitted set of Characters

- Protection from Malicious and Special

Characters (escape special Characters)

APP-09 Software errors displayed on the screen should

not contain any technical details especially

information for debugging and testing.

It is preferable to design error handling the way

that instead of technical details, display an error

ID error message

APP-10 All elements must be in compliance with local

and international laws and regulations. (Type of

traces, processing, reporting obligations, etc.)

Example: banking application must be in

compliance with National Bank of Georgia

requirements.

4. Application Security





Follow

ed

Not

Followed N/A

ACC-01 Unique username and password should be used

for Authentication in the system

ACC-02 Each User should have only one Account in the

system

ACC-03 Information about Bank Employees stored in the

system should not differ from the information

stored in the HR database of the Bank (Name,

Surname, Position, Personal Number, Etc.)

ACC-04 System should comply with Password Policy of

The Bank

ACC-05 After successful authentication, new unique

session should be created. In case of inactivity of

15 minutes the session should be terminated.

ACC-06 Authentication information (password, token,

etc.) should be encrypted prior to transmission in

communication channel

ACC-07 Both, Successful and Unsuccessful

authentication events should be logged stored

and available for further audit.

ACC-08 In case of unsuccessful authentication, the error

message returned must not specify whether it is

the login or the password that is incorrect.

ACC-09 System should support Role Based Access

Control

ACC-10 Access rights should be pre-defined Formalized

and approved as well as detailed Matrix of rights

describing System roles with corresponding

position of the bank

ACC-11 For the new system user management process

should be formalized and enforced.

ACC-12 Authentication mechanism of the system should

be integrated with one of the Centralized

authentication systems of the bank (Active

Directory, TBC_AUTH)

ACC-13 There should be predefined all operations which

will require additional authorization e.g. “four-

eye” principle

ACC-14 Privileged Users of the system should use

advanced authentication mechanism (Two Factor

Authentication)

ACC-15 Access to system, security and audit information

is only available to Audit, system and security

administrators.

ACC-16 Sensitive Data in Test and development

environment should be anonymized. It is




forbidden to use Production data with testing and

development means.

ACC-17 Based on request, with the means of remote

support of the system access can be granted to

representative of 3rd party. Access should be

granted only using secure solution enabling

logging, Identification, monitoring, and control of

the remotely logged in Party

5. Mobile Application (General)


Follow

ed

Not

Followed N/A

MOB-01 Do not store any passwords or secrets in the

application binary. Do not use a generic shared

secret for integration to backend (like embedded

password in code). Mobile application binaries

should not be easily downloaded and reverse

engineered.

MOB-02 The final application must be compiled in release

mode and protected with the use of an

obfuscation tool

Proguard

MOB-03 The application must use HTTPS connections to

access network resources and never override

the standard security mechanisms provided by

the system (e.g. for validating certificates).

MOB-04 Do not store/cache sensitive data (including

keys) unless they are encrypted and if possible

stored in a specially allocated secure memory.

MOB-05 Apply the principle of minimal disclosure - only

collect and disclose data which is required for

business (pre-identified according business

need). Data sensitivity level and whether it is

appropriate to collect, storage and use of each

data type must be identified in the design phase.

MOB-07 No passwords to be stored on the device

MOB-08 Ensure passwords and security keys are not

visible in caches, logs or any other stored data.

MOB-09 Applications must be designed and provisioned

to allow updates for security patches, taking into

account the requirements for approval by app-

stores.

MOB-10 Implement code signing mechanism in the

application. Do not share code signatures with

other applications installed on the same device,

as it implies inherent trust between applications.

If code is shared plan code signing mechanism

properly to avoid override with untrusted




software. If application is distributed through

publicly accessed service/platform (such as

Google Play Store) code signing must be taken

into higher priority.

MOB-11 Implement certificate pinning mechanism

MOB-12 Prohibit of running application once

jailbroken/rooted device was detected

6. Mobile Application (Android)


Follow

ed

Not

Followed N/A

AND-01 Use the Google provided tools, in their latest

version, with the highest possible SDK, and patch

level

firebase

AND-02 Encryption must be implemented in the secure

way. Sensitive information must be encrypted as

soon as possible and should not reside in the

permanent memory.

AND-03 Sensitive information should not exist outside of

the dedicated protected memory Do not write data on

external storage

Use internal storage

Set access

MODE_PRIVATE

Use Sandbox

Avoid

MODE_WORL_WRITA

BLE/READABLE

If necessary use

Content Providers

AND-04 Protect credentials either by storing them on a

server or by encrypting them. Alternatively

tokenization mechanism can be used

AND-05 Protect all sensitive data stored on device, using

the well-known and approved crypto APIs AES 256;

BouncyCastle; Java

AES Crypto; Android

Keystore system;

JCA;KeyChain

AND-06 Memory allocation error checks must be

performed, therefore memory size must be

controlled correctly

ASLR, NX, ProPolice,

safe_iop, OpenBSD

dlmalloc, OpenBSD

calloc, and Linux

mmap_min_addr

AND-07 Minimize object lifecycle (discard when

unnecessary)

AND-08 Specific classes must be used to hold sensitive

data in text format, which can overwrite the

string content once it is not used anymore.

Don't use immutable

structures (e.g.,

String and BigInteger)




to represent secrets.

Nullifying these

structures will be

ineffective: the

garbage collector

may collect them, but

they may remain on

the heap after

garbage collection

use char array

instead

AND-09 Memory allocation and manipulation must be

strictly controlled. Use only final parameter

provided in the dynamic string

ASLR, NX, ProPolice,

safe_iop, OpenBSD

dlmalloc, OpenBSD

calloc, and Linux

mmap_min_addr

AND-10 Data exchange over JNI (Java Native Interface)

must be strictly controlled when application

makes calls code written in other language.

Improper error handling can render security

flows

AND-11 Check SQL query parameters for SQL injection

patterns and use parameterized queries

AND-12 Implement strict rules for “input validation”

smechanisms for any data especially from

outside sources. Render only validated data and

user input.

AND-13 Deactivate copy-cut, clickable links, auto-

completion and auto-correction on fields holding

sensitive data

Password

PIN

PID

CARD DATA

AND-14 Use HTTPS connections

AND-15 Avoid running background services if possible

AND-16 Clear active session and sensitive data, revoke

credentials and require repeat login when

application goes to the background

AND-17 Do not use shared UserID and shared processes

AND-18 Implement manual testing process and code

review procedure before releasing final product

to check for security issues

AND-19 Encrypt data before it is backed up in system

includes backup process

AND-20 Do not use sync services

AND-21 Avoid using push notifications if possible, else

implement strong payload checking mechanism

and avoid pushing sensitive data.




AND-22 Minimize access to any kind of personal data

(including data from the system applications or

from the hardware) in the application.

Inform the user if doing so and avoid storage or

transmission of any personal data to a remote

location.

7. Mobile Application (IOS)


Follow

ed

Not

Followed N/A

IOS-01 Use keychain for storing sensitive information

such as credentials

IOS-02 In controlled environments, use “data

protection” entitlement to implement encryption

for data stored on the device. For “public”

applications, use the CommonCrypto framework

to encrypt data stored on the device.

Data Protection level

Complete -

NSFileProtection

Complete

IOS-03 Check objects initializations for errors, at every

development stage within the code

IOS-04 Do not use lower-level programing language

(such as C) for memory management, rather use

higher-level languages, that have inbuilt

communication protocols on hardware level.

IOS-05 Specific classes must be used to hold sensitive

data in text format, which can overwrite the

string content once it is not used anymore.

Don't use immutable

structures (e.g.,

String and BigInteger)

to represent secrets.

Nullifying these

structures will be

ineffective: the

garbage collector

may collect them, but

they may remain on

the heap after

garbage collection

use char array

instead

IOS-06 Check SQL query parameters for SQL injection

patterns and use parameterized queries

IOS-07 Deactivate auto-completion on fields that may

hold sensitive data.

IOS-08 The application must use HTTPS connections to

access network resources and never override

the standard security mechanisms provided by

the system (e.g. for validating certificates).

IOS-09 Clear “Paste” board buffer as soon as it’s

content was Pasted (no longer useful).




IOS-10 Do not open documents with a

UIDocumentInteractionController to avoid

unsecure preview or automatic hidden malware

execution.

IOS-11 Avoid running background services if possible

IOS-12 Clear active session and sensitive data, revoke

credentials and require repeat login when

application goes to the background

IOS-13 Avoid using push notifications if possible, else

implement strong payload checking mechanism

and avoid inserting sensitive data.

IOS-14 Minimize access to any kind of personal data

(including data from the system applications or

from the hardware) in the application.

Inform the user if doing so and avoid storage or

transmission of any personal data to a remote

location.

IOS-15 Implement external checks during the

fingerprint and FaceID authentication. Avoid

using the standard classes like “LAContext”

Use keychain

8. Logging


Follow

ed

Not

Followed N/A

LOG-01 In order to have a unique and reliable logging

reference, the system supports clock

synchronization system (NTP).

LOG-02 Logs should not contain any sensitive

information (password, PIN, OTP, etc.)

LOG-03 Logs should be stored in SYSLOG format

LOG-04 System should have ability to send logs to

external syslog server

LOG-05 At Least following information should be logged:

Date

Time

Username/User ID

IP Address

Action

Status (Success or Failure)

LOG-06 If exchanging electronic messages, these

messaged should signed.

Documents

Payment Fraud Solution System