The NICE Actimize Xceed platform consists of Visual Analytics, an Integrated Risk Database, Omni-Channel Risk Scoring, and an Enterprise API to give your payment platform and end customers the best protection against fraudulent attacks.

We truly mean business when it comes to protecting our customers’ financial assets. With more than 100s of payment platforms as our customers, ranging in scope from millions in assets, we analyze the behavior of millions of commercial and retail account holders, and protect payment activities each year, making us the #1 behavioral analytics platform for Fraud detection.

Our integration partners include:

NICE Actimize Xceed supports two ways to build an integration with Payment Platforms.

1. API

Highly scalable web services framework that allows real-time data capture from multiple sources across the entire institution and returns real-time risk scores. Drives automated intervention such as transaction hold/release, step up authentication, OOB and other strategies.

Overview
The NICE Actimize Xceed API supports the following requests and responses:

XML based request and response are supported via SOAP API integration. All RESTful request and response formats are JSON. Sending an event involves performing an HTTP POST to a NICE Actimize specified URL.

NICE Actimize Xceed supports following API formats:

SOAP API
XML Payload Example

RESTful API
JSON Payload Example

Example of API Response
1. REST API RESPONSE using Callable Risk API

2. SOAP API Response

Restricted Access
Access to the receiving NICE Actimize Xceed application is restricted to authorized originating IP Addresses. All requesting IP addresses must be whitelisted by NICE Actimize Xceed for development, test, and production environments.

Secure Transport
All API requests are transferred over encrypted HTTP/SSL connections. SSL keys are provisioned with a strength of 2048-­bits. Data transferred over SSL is protected with symmetric encryption algorithms using the RC4, 3DES or AES ciphers with key sizes of 128 bits or higher. SSL is additionally “strengthened” according to best practices (128-bit or higher keys, no SSLv2, disable “weak” ciphers, disable re-­negotiation).

Authentication
All service providers and applications must be approved and authenticated. A unique service ID, subdomain, platform ID, and hash key are issued for each customer and platform provider as part of the provisioning process.

Signing API Requests
A shared secret key is generated for each customer. This value, along with other unique customer identifiers, is used to generate a SHA1 hash to verify the API request. Should the verification fail for any reason, a failure response is returned, and the event is not processed. This prevents any data from being manipulated in transit.

In order to make sure that the payload of a NICE Actimize Xceed Enterprise API request is legitimate, we provide application developers with a secret key that is used to create a hash value that can be verified on our end of the system. In the SOAP request, there are 5 required fields:

For addEvent:
platformId	(e.g. 3)
serviceId	(e.g. 210021)
channel	(e.g. OLBBusiness)
secretKey	(e.g. 311a5439c8bda8ef)
payLoad	(e.g.  ... )

The hash is created by getting the SHA-­‐1 sum from the concatenation of platformId + serviceId + channel + secretKey + payLoad.

For addAsyncEvent:
For asynchronous API requests, there is an additional field required to generate the SHA-­1 sum, the callbackId. This should be appended after the payload of the request. For example:

platformId + serviceId + channel + secretKey + payLoad + callbackId

The callbackID identifies a callback URL that points to a service that will consume asynchronous callback requests initiated from the NICE Actimize Xceed web service.

Validation Errors
• Validation Errors are enumerated and returned.
• Successful Events are processed

All Other Types of Errors
• When any other error is encountered, processing is stopped, and the nature of the error is returned
• The Event id of the first occurrence of error will also be returned.
• Further processing is halted

2. File Based Integration

Overview
Where real-time API integration is not feasible due to limitations on the payment platform side, NICE Actimize Xceed can support a file-based integration with a payment platform.

Data snapshots can be made available at a regular interval in .csv file format that NICE Actimize Xceed risk application can process and perform risk assessment.

Setup and Connectivity
NICE Actimize Xceed supports configurable frequency for file delivery. FI can provide files as often as every 15 minutes, hourly, once a day or any other frequency that is suitable. File transmission will be supported over secure SFTP hosted by NICE Actimize Xceed.

Security Requirements

Restricted Access
Access to the receiving NICE Actimize Xceed application is restricted to authorized originating IP Addresses. All requesting IP addresses must be whitelisted by NICE Actimize Xceed for development, test, and production environments.

1. Under what scenarios should an application send system-generated events that are not a direct response to an account holder’s action?
Send system-generated activities that intervene in the intended workflow of the account holder.

Example: The system terminates an account holder’s session because the session lasts beyond the permissible banking hours designated to the account holder. In such an event, the SystemDenied event should be sent.

Example: The system automatically logs out the user due to idle time exceeding timeout value.
Send system-generated activities when they contain a message that requires an immediate response from the account holder, especially when the timeliness and correctness of the response could impact the account holder’s future workflow.

Example: The system calls or sends a text message to the account holder to verify his/her identity prior to submitting a wire. In this case, the MFAChallenge event should be sent. Example: The system automatically registers an account holder’s device to bypass future challenges after the account holder successfully authenticates. This should trigger a DeviceRegister event to be sent.

2. What value should be sent when required field data is unavailable?
When a required field is unavailable, follow these guidelines:

For required field of String type, use “Unknown”
For required field of Date type, use “0000-00-­‐00”
For required field of Token type, use “Unknown”
For required field of Boolean type, use “False”
For required field of double type, use “-­‐1.00”

3. What value should be sent when the data does not match any of the enumerated values for a token field?
Send “Other” and then include a name-value pair in the DisplayFields element.

For example:
Other
SystemAccessed=EmployeePortal | name=value | …

4. What event should be sent when there is an account type that doesn’t match any predefined AccountType in the API?
Please send “Other” for AccountType and then send a description in Display Fields.