Skip to main content

Security, Compliance & Quality

1. Security Requirements​

Your anomaly detection service must implement the following security measures:

1.1 HTTPS Protocol​

The anomaly detection service is external to Candescent data centers. All communication must use HTTPS with TLS 1.2 or higher with server certificate authentication.

1.2 Client Certificate Authentication (Optional)​

In addition to server certificate authentication, you may implement client certificate authentication where Candescent must present a signed certificate verifying their identity during the HTTPS handshake.

1.3 HTTP Basic Authentication​

You must validate the HTTP Basic Authentication header passed by Candescent.

Implementation Requirements:

  1. Issue a pair of client credentials (Client ID and Client Secret) to Candescent
  2. Credentials must be kept secure
  3. Validate the Authorization header on every request

Authorization Header Format:

Authorization: Basic Base64(client_id:client_secret)

Example:

Authorization: Basic OHFvcDFjNmwxdjlzNnRmMm5iaDA6cmU0aTA5aHZkcTY5bjAwZG45Mzg=

1.4 IP Whitelisting​

Your service should whitelist Candescent IP addresses. The specific IP addresses will be provided during the integration process.

1.5 Security Configuration Options​

You may implement one or more of the following security mechanisms:

  • Client Certificate Authentication
  • HTTP Basic Authentication
  • Both Client Certificate AND HTTP Basic Authentication

2. Nonfunctional Requirements​

2.1 Performance Expectations​

Your anomaly detection service must meet the following performance requirements:

APIIdeal Response TimeMaximum Response Time
getRiskProfile< 200 milliseconds2 seconds
deleteUserBankingActivities< 200 milliseconds2 seconds
createBankingActivities (bulk)< 2 seconds5 seconds

Circuit Breaker Behavior:

If response times consistently exceed the maximum thresholds, Candescent will:

  1. Open the circuit (using circuit breaker pattern)
  2. Respond to UI clients with a challenge response to the user
  3. Keep the circuit open until your API performance recovers

2.2 High Availability​

As an external service, you are responsible for ensuring:

  • High availability
  • Performance consistency
  • System reliability
  • Disaster recovery capabilities

2.3 Prerequisites for Production​

Historical Data Loading:

Historical user event data must be loaded for each Financial Institution prior to enabling Anomaly Detection for that institution in production.

  • Recommended duration: 90 days of historical event data
  • Data delivery: Via the bulk API (createBankingActivities) in a streaming manner
  • Source: Candescent's data platform system

3. Status Codes and Messages​

Your implementation must return appropriate status codes. The following status codes are defined:

Status CodeTypeMessage
SUCCESSSuccess(Operation completed successfully)
SUCCESS_RISK_PROFILE_NOT_EVALUATEDSuccess(Request accepted but risk not evaluated)
ERROR_INTERNAL_SERVERErrorOperation failed due to some internal server error
ERROR_NOT_SUPPORTEDErrorReal-time risk score not supported by product license
ERROR_INVALID_CLIENT_IDErrorInvalid client id
ERROR_INVALID_MSGErrorThe message passed to the API is invalid
ERROR_RISK_PROFILE_CHECK_NOT_CONFIGUREDErrorRisk profile check is not configured
ERROR_INVALID_TRANSACTION_IDErrorInvalid or no transaction id header passed
ERROR_TIMEOUTErrorRequest was received successfully but there was an internal server timeout. Risk engine was not able to return a risk score
ERROR_MAINTENANCEErrorSystem unavailable due to maintenance
ERROR_INVALID_USER_IDErrorInvalid User Id
ERROR_INVALID_LOGIN_NAMEErrorInvalid Login Name

This document is confidential and proprietary. The information contained herein may not be copied, reproduced, transmitted, or used without the express written consent of Candescent Corporation.