Your suggested change has been received. Thank you.

close

Suggest A Change

https://thales.na.market.dpondemand.io/docs/dpod/services/kmo….

Thales Logo

All

  • All
back

Other

Frequently asked questions

search

Please Note:

Frequently asked questions

This section contains the commonly asked questions about OIP Risk Management SDK.

Why should I use OIP Risk Management SDK?

OIP Risk Management SDK aims to improve the security of online transactions as it allows banks to assess every online banking session in real time.

What is visitID?

visitID is an unique ID provided by OIP Risk Management SDK which needs to be sent to the application backend. The application backend uses visitID to enquire on the risk score generated from Risk Engine backend.

Will OIP Risk Management SDK ensure the full security of a transaction?

No, it only determines the risk level involved with the transaction on the device. The application or application backend can use this risk score to calculate the risk before taking further action.

Is communication with Risk Engine backend secure?

Communication with Risk Engine backed uses only HTTPS protocol over TLS layer. To protect from man-in-the-middle attack, it rejects hostname-mismatch, rejects self-signed certificate and accepts only root CA trusted certificate. OIP Risk Management SDK uses only strong cipher suits for communication, it rejects any weak cipher suite that is not present at the Risk Engine backend server.

What are the different groups of signals it will read from the device?

It reads Device, Location, Network, Platform, PlatformSettings, App, SDK, SIM, NetworkSettings, Browser, BehavioSec and ThreatMetrix. Refer to Signal Groups and corresponding Signals to get an updated list of signal groups and their corresponding signals.

Any third-party library used in this framework?

Yes, BehavioSec, ThreatMetrix SDKs are used.

Why and when Prefetch should be called?

Any signal which may consume time for collection in OIP Risk Management SDK may introduce latency during signal collection. By calling the startPrefetchSignals method, signals are collected and stored before the actual collection.

For example, startPrefetchSignals can be called during the launch of a screen containing a transaction event such as Login or Add Beneficiary. When exiting from the screen, stopPrefetchSignalscan be called.

What is ATS?

ATS or the App Transport Security is the security feature on iOS which aims to improve the security of network request. ATS encourages security by imposing the best practices. The most important is by default, it allows only HTTPS request. So, no HTTP request can be made without making modifications on the ATS settings.

There are other default settings to be made for further improved security. The application prefers TLS 1.2 communication to SSL as TLS is of higher version than SSL. You can still connect to the HTTP request by making changes on the ATS setting. There are other parameters such as cipher suite, self-signed certificate, host mismatch and others that come under the ATS settings to improve the security.

How does the signal collection timeout work?

There are three different timeouts used in OIP Risk Management SDK. * Signal collection global timeout

The time (in milliseconds) to collect a signal in `requestVisitID` method before returning an error. If a signal is not collected within the time interval, OIP Risk Management SDK will send a timeout signal error (`524, "Signal has timed out"`) to the server. The default value is set to 2000 milliseconds.

This is used in the `GAHCoreConfig.Builder.setSignalCollectionGlobalTimeout()` API on Android.

This is used in the `[GAHCoreConfig setSignalCollectionGlobalTimeout:]` API on iOS.

Note

Calling the startPrefetchSignals method before the requestVisitID method reduces the chance of having a timeout error because the signals will have been cached.

  • Signal prefetch timeout

    The time (in seconds) to collect a signal before returning an error.

    This is similar to the signal collection in global timeout, but it applies to the startPrefetchSignals method. The difference is, when the timeout is reached, it will not send a timeout signal to the server. Instead, it will return error via the requestPrefetchStatus callback. In the subsequent requestVisitID method, OIP Risk Management SDK will attempt to collect the signal again. The default value is set to 5 seconds.

    This is used in the GAHGemaltoSignalConfig.Builder.setSignalPrefetchTime() API on Android.

    This is used in the [GAHGemaltoSignalConfig setSignalPrefetchTimeout:] API on iOS.

  • Signal cache timeout

    This timeout (in seconds) applies to signals cached during the startPrefetchSignals method. The signals cached during this interval are usable in the subsequent requestVisitID method. Otherwise, the requestVisitID method will try to fetch the signals again. The default value is set to 300 seconds.

    This is used in the GAHGemaltoSignalConfig.Builder.setSignalCacheTime() API on Android.

    This is used in the [GAHGemaltoSignalConfig setSignalCacheTimeout:] API on iOS.

The following figure illustrates the behavior of the three timeouts during the startPrefetchSignals method and requestVisitID method. The receiving of requestVisitID method is fast as it uses the signals cached during the startPrefetchSignals method.

image.png

How should I set the timeout to maximise the success rate for signal collection and visitID?

For signal collections that require internet connection and may take a significant amount of time such as activities in Threatmetrix, the following steps will maximise the success rate of signal collection. * To prevent an unsuccessful signals fetching from the startPrefetchSignals method, extend the signal prefetch timeout especially when your internet speed is low. * Call the startPrefetchSignals method prior to calling the requestVisitID method. For example, when the registration page is shown, call the startPrefetchSignals method. When the end user taps Register, the requestVisitID method is called. This will lead to a shorter loading time as requestVisitID method uses the signals cached from the startPrefetchSignals method. * Extend the signal cache timeout, if necessary, to ensure that the signals cached in the startPrefetchSignals method can be used in requestVisitID method. The signals may be outdated if the timeout is set too long. * In certain scenarios where requestVisitID method is not able to use the cached signals from the startPrefetchSignals method (for example, when the end user takes a long time to fill the registration page), extend signal collection global timeout so that the signals are collected successfully in requestVisitID method.

On this page