Developer Resources

Guardian Analytics’ 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.

Guardian analytics detects & intervenes in real-time

Platform Integrations

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:

Retail Online

• ACI – Mobile Banking
• Alkami
• Backbase
• BioCatch
• ConnectFSS
• Digital Insight – Digital Banking Platform (Retail)
• Fiserv – COASP
• Fiserv – Corillian Online Hosted
• Fiserv – Corillian Online Licensed
• Fiserv – DNAweb
• Fiserv – Mobiliti
• Fiserv – Open Solutions
• Fiserv – Xroads
• Fiserv – Retail Online
• Fiserv SecureNow
• Fiserv – Virtuoso
• Finastra- Harland – UltraData
• Infosys – Finacle
• Jack Henry – Banno
• Jwaala
• Kony
• Malauzai
• MShift
• Q2 – eBanking
• Tyfone
• Wescom Resources Group

Business Online

• ACI – Enterprise Banker
• Backbase
• Bottomline – Business Financial Solutions
• Digital Insight(NCR) – Business Banking
• Fiserv – Business Online
• Fiserv – Commercial Banking
• Fiserv – Corillian Online Hosted
• Fiserv – Corillian Online Licensed
• Fiserv SecureNow
• Jack Henry – Treasury Management
• Jack Henry – NetTeller
• Jack Henry – iPay

Wire

• Fedwire – Fedline Advantage
• Fedwire – Fedline Direct
• Fedwire – FedTransaction Analyzer
• FIS – eGifts
• FIS – eWire
• Fiserv – Wire Manager
• Fiserv – WireXchange
• Finastra- Fundtech – ACHplus
• Finastra- Fundtech – PAYplus Connect (formerly GFX)
• Finastra- Fundtech – PAYplus USA
• Finastra – Total Payment
• Ocean Systems – Fedlink
• Pathfinder – WITS

ACH-ODFI/RDFI

• Bottomline – Business Banking (BB)
• First Data – FundsXpress
• FIS – ACH
• FIS – BeB
• FIS – CLK
• Fiserv – ACH Manager
• Fiserv – PEP+
• Fiserv – Premier ACH
• Jack Henry – Silverlake

Zelle

• Tyfone

Xceed Callable Risk Score API Datasheet

Xceed Callable Risk Score API offers financial institutions or FinTech providers the ability to assess the risk level of a banking customer in real-time and execute risk-based intervention actions, by retrieving the risk score of the banking customer via API from tthe Xceed fraud detection platform. The Callable Risk Score API can be integrated with any system used for user authentication and interdiction.
Learn More >

Developer’s Resources

Guardian Analytics 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 Guardian Analytics API supports the following requests and responses:

Requests Description
addEvent A request where the payload includes attributes for a single event. The request includes a parameter to require only a simple acknowledgement or more detailed risk score information.
addMEvents Send multiple synchronous events – returns an ACK but with no results / scores. This is meant for historical / batch loading that do not require a response.
addAsyncEvent A request where the payload includes attributes for a single event. Each request is acknowledged synchronously, however, the request can include a parameter to indicate a callback ID where the response will be sent asynchronously after the request is processed.
addMAsyncEvents Send multiple asynchronous events – returns an ACK but with no results / scores. This is meant for historical / batch loading that do not require a response.
Response Description
Results Sent in response to requests. Includes an acknowledgement return code indicating success or failure of the request and can also optionally include more detailed risk score information.

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 Guardian Analytics specified URL.

Guardian Analytics supports following API formats:

SOAP API
XML Payload Example

Copy to Clipboard

RESTful API
JSON Payload Example

Copy to Clipboard

Security Requirements

Restricted Access
Access to the receiving Guardian Analytics application is restricted to authorized originating IP Addresses. All requesting IP addresses must be whitelisted by Guardian Analytics 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 Guardian Analytics 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 Guardian Analytics 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

Return Code Category Reason Disposition
SUCCESS All Requests Event received successfully. Processed normally.
NOT_SUPPORTED All Requests Real-­‐time risk score not supported by product license. Recommended action: contact technical support to request upgrade. Not processed.
BAD_SERVICE_ID All Requests Service ID provided is invalid or unreadable. Recommended action: Fix service ID and retry. Not processed.
HASH_KEY_FAIL All Requests Hash key doesn’t match expected key. Recommended action: Fix hash key and retry. Not processed.
XML_VALIDATION_FAIL All Requests Format of payload is invalid. Recommended action: Fix XML formatting error and retry. Not processed.
MISSING_XML_VERSION All Requests Column 3 Value 6 Not processed.
XSD_VERSION All Requests Column 3 Value 7 May be processed, warning given.
UNSUPPORTED_XML_VERSION All Requests Column 3 Value 8 Not processed.
ERROR All Requests Column 3 Value 9 Not processed.
REQUEST_ERROR Synchronous Requests Column 3 Value 10 Not processed.
TIMEOUT Synchronous Request, Response Required Column 3 Value 11 Will eventually be processed.
INVALID_MSG Synchronous Request, Response Required Column 3 Value 12 Not processed, skipped.
MSG_SKIPPED Synchronous Request, Response Required Description of why the message was skipped. Recommended action: Contact
technical support to report issue, do not retry.
Not processed, skipped.
MSG_OOO Synchronous Request, Response Required Message was received out of order (usually from prior day). Recommended action: Contact technical support to report issue, do not retry until issue is resolved. Not processed, skipped.
WRONG_NUM_EVENTS AddMEvents or AddMAsyncEvents The number of events in the payload did not match the number of events sent in the numEvents parameter. Recommended action: Fix count of event to match the number of events included in request payload and retry. May be processed, warning given.
MAINTENANCE All Requests, Response Required The request was received and queued for processing but the system cannot return a risk at this time. Recommended action: No action necessary, messages will be processed automatically when normal operations resume. Will be processed after maintenance interval.
DATA_COLLECTION All Requests, Response Required The request was received and risk scored but the risk score should not be relied on because the Guardian Analytics deployment is still in the initial pre-­‐production, data collection phase. Recommended action: No action necessary. The risk score should not be used for intervention.
NO_RISKACTION_CONFIGURED All Requests, Response Required The request was received and risk scored but there was no policy defined specifying a risk action to return. Recommended action: Ensure that there is at least one policy defined in the Risk Application to return a recommended risk action. See product documentation for details. Processed normally.
INVALID_CALLBACK All Requests, Response Required The callback ID in the request did not match a valid callback URL configured for the platform provider or for the tenant.
Recommended action: Correct the callback parameter and retry.
Not processed, skipped.
INVALID_CHANNEL All Requests The channel parameter did not contain a valid value. It should default to “Wire”. Recommended action: Correct the channel parameter value and retry. Not processed, skipped.

2. File Based Integration

Overview
Where real-time API integration is not feasible due to limitations on the payment platform side, Guardian Analytics 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 GA risk application can process and perform risk assessment.

Setup and Connectivity
Guardian Analytics 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 GA.

Security Requirements

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

FAQs

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.