Risk & Compliance API | FinTrace Intelligence

Questions worth exploring

Define the contract before the connection.

An API discussion is most useful when it begins with your application’s needs. Describe the information you want to request, how it would be used, and how your application should respond when information is unavailable. The Risk & Compliance API delivers wallet, transaction, and sanctions risk signals over REST and streaming endpoints — see docs.fintraceintelligence.com for the full reference.

Your application01
Define required data
List the inputs your application can supply and the fields it needs back.
Your application02
Choose the relevant risk signal
Pick the signal that fits the decision your application supports.
Your application03
Submit an API request
Send the request with the credentials and inputs the contract requires.
Request →
FinTrace API04
Receive a structured response
Read the result, its context and its limits from a structured response.
← Response
Your application05
Handle unavailable or uncertain results
Treat missing, partial and failed results as exactly that, never as clear.
Your application06
Store evidence and continue
Keep the response with your record and move the workflow on.

Illustrative integration flow. The actual contract is in the API documentation.

Keep in view · 01
Inputs and outputs
Describe the data your application would supply and the information it needs in return. Ask to review a verified endpoint specification and its field definitions.
Keep in view · 02
Access and operating limits
Ask about authentication, permission scope, usage limits, and access arrangements. Identify which operational requirements matter to your engineering team.
Keep in view · 03
Response handling
Discuss how available, incomplete, and unsuccessful responses would be distinguished. Ask how version changes and documentation updates would be communicated.

Interactive API showcase

See what an integration conversation looks like.

Five illustrative evaluation categories with placeholder requests and responses. Use them to frame your questions. Which categories exist, and their exact endpoints, are confirmed in the documentation and during evaluation.

API showcase · Illustrative evaluation categoriesPlaceholders only

POST{BASE_URL}/{VERSION}/{WALLET_RISK_PATH}Illustrative category

Request

Headers

Name	Value	Note
Authorization	<credential> ••••••••	Masked. Scheme to confirm
Content-Type	application/json	Illustrative

Request parameters

Parameter	Type	Description
subject	string	Required. The wallet address to assess.
network	string	Required. Network identifier.
options	object	Optional. Illustrative placeholder.

JSON request body

{
  "subject": "<wallet-address>",
  "network": "<network-id>"
}

Response

200 OKVersion {VERSION}

{
  "risk_result": "<value>",
  "confidence": "<level>",
  "context": {
    "entity_reference": "<optional>",
    "sources": ["<source-ref>"]
  },
  "warnings": [],
  "timestamp": "<iso-8601>",
  "version": "{VERSION}"
}

Status codes and error states

2xxSuccess. Read the result, context and warnings.
IncompletePartial information. Not a clear result.
4xxValidation, authentication or usage problem.
5xxService unavailable. Not a clear result.

Field descriptions

risk_resultPlaceholder

The risk outcome for the subject. Names and allowed values are defined in the documentation.

confidencePlaceholder

How much weight the result deserves. Shown so your application can display it.

warningsArray

Limitations or messages to surface to a reviewer. An empty array does not mean the result is clear.

POST{BASE_URL}/{VERSION}/{TRANSACTION_RISK_PATH}Illustrative category

Request

Headers

Name	Value	Note
Authorization	<credential> ••••••••	Masked. Scheme to confirm
Content-Type	application/json	Illustrative

Request parameters

Parameter	Type	Description
transaction	string	Required. A transaction identifier.
network	string	Required. Network identifier.
direction	string	Optional. Illustrative placeholder.

JSON request body

{
  "transaction": "<transaction-id>",
  "network": "<network-id>"
}

Response

200 OKVersion {VERSION}

{
  "risk_result": "<value>",
  "confidence": "<level>",
  "context": {
    "counterparties": ["<ref>"],
    "sources": ["<source-ref>"]
  },
  "warnings": [],
  "timestamp": "<iso-8601>",
  "version": "{VERSION}"
}

Status codes and error states

2xxSuccess. Read the result, context and warnings.
IncompletePartial information. Not a clear result.
4xxValidation, authentication or usage problem.
5xxService unavailable. Not a clear result.

Field descriptions

risk_resultPlaceholder

The risk outcome for the transaction.

contextObject

Supporting information a reviewer would need to understand the result.

timestampString

When the result was produced. Store it with your record.

POST{BASE_URL}/{VERSION}/{SANCTIONS_SIGNAL_PATH}Illustrative category

Request

Headers

Name	Value	Note
Authorization	<credential> ••••••••	Masked. Scheme to confirm
Content-Type	application/json	Illustrative

Request parameters

Parameter	Type	Description
subject	string	Required. An address or counterparty reference.
network	string	Required for addresses.
sources	array	Optional. Which sources to consider. To confirm.

JSON request body

{
  "subject": "<address-or-counterparty>",
  "network": "<network-id>"
}

Response

200 OKVersion {VERSION}

{
  "risk_result": "<value>",
  "match_type": "<direct | indirect | none>",
  "confidence": "<level>",
  "context": { "source_reference": "<ref>" },
  "warnings": ["<limitation>"],
  "timestamp": "<iso-8601>",
  "version": "{VERSION}"
}

Status codes and error states

2xxSuccess. Read the result, context and warnings.
IncompletePartial information. Not a clear result.
4xxValidation, authentication or usage problem.
5xxService unavailable. Not a clear result.

Field descriptions

match_typePlaceholder

Whether a direct, indirect or no relevant result was found. Never a compliance guarantee.

source_referencePlaceholder

The source behind the result. Which sources exist is confirmed in evaluation.

warningsArray

Any limitation, for example incomplete source coverage.

POST{BASE_URL}/{VERSION}/{ENTITY_CONTEXT_PATH}Illustrative category

Request

Headers

Name	Value	Note
Authorization	<credential> ••••••••	Masked. Scheme to confirm
Content-Type	application/json	Illustrative

Request parameters

Parameter	Type	Description
subject	string	Required. The address to look up.
network	string	Required. Network identifier.

JSON request body

{
  "subject": "<wallet-address>",
  "network": "<network-id>"
}

Response

200 OKVersion {VERSION}

{
  "entity": "<reference-or-null>",
  "confidence": "<level>",
  "context": { "sources": ["<source-ref>"] },
  "warnings": ["<attribution is not legal ownership>"],
  "timestamp": "<iso-8601>",
  "version": "{VERSION}"
}

Status codes and error states

2xxSuccess. Read the result, context and warnings.
IncompletePartial information. Not a clear result.
4xxValidation, authentication or usage problem.
5xxService unavailable. Not a clear result.

Field descriptions

entityPlaceholder

A sourced entity reference, or null when none is available. Null is not a clear result.

confidencePlaceholder

Confidence in the attribution.

warningsArray

Attribution is a reference, not a statement of legal ownership.

SUBSCRIBE{STREAM_URL}/{VERSION}/{EVENT_STREAM_PATH}Illustrative category

Connection

Headers

Name	Value	Note
Authorization	<credential> ••••••••	Masked. Scheme to confirm
Content-Type	application/json	Illustrative

Subscription parameters

Parameter	Type	Description
subscription	object	Concept only. Availability is confirmed in evaluation.
event_types	array	Which event types to receive. To confirm.

Subscription body

{
  "subscription": {
    "event_types": ["<type>"]
  }
}

Event payload

EventDelivery guarantees: to confirm

{
  "event": "<type>",
  "subject": "<wallet-address>",
  "change": "<what changed>",
  "timestamp": "<iso-8601>",
  "version": "{VERSION}"
}

Status codes and error states

2xxSuccess. Read the result, context and warnings.
IncompletePartial information. Not a clear result.
4xxValidation, authentication or usage problem.
5xxService unavailable. Not a clear result.

Field descriptions

eventPlaceholder

The event type. Supported event types are confirmed in evaluation.

changePlaceholder

What changed since the previous signal.

deliveryTo confirm

Delivery guarantees and retries are confirmed in evaluation.

Illustrative categories, endpoints and fields. None of these paths or names is a documented endpoint. See docs.fintraceintelligence.com for the reference.

Request and response contract

Know exactly what goes in and what comes back.

A dependable integration starts with a contract you can test against: which fields are required, what a valid value looks like, and which parts of a response you must store and show.

Request

What your application sends

Field	Type	Presence	Example value	Validation rule
subject	string	Required	<wallet-address>	Non-empty. Format depends on the network.
network	string	Required	<network-id>	One of the supported network identifiers (to confirm).
options	object	Optional	{ … }	Unknown keys handled per the documentation (to confirm).
reference	string	Optional	<your-reference>	Free text your application can use to correlate a call.

Response

What your application receives

Field	Type	Carries	Purpose
risk_result	placeholder	Risk result	The outcome for the subject.
confidence	placeholder	Confidence indicator	How much weight the result deserves.
context	object	Supporting context	Information a reviewer needs to understand the result.
context.sources	array	Source references	Where the result and its context come from.
timestamp	string	Timestamp	When the result was produced, for your evidence record.
version	string	Version	Which version of the contract produced the response.
warnings	array	Warnings or limitations	Messages about coverage or certainty. Always surface them.

Placeholders, not a schema. Field names, types and rules here are neutral placeholders that show the kind of contract to expect. The verified specification and field definitions are in the API documentation and are reviewed during evaluation.

Response handling

Design for every state, not just success.

Your application will receive more than successful responses. Decide up front how each state looks to a user and to your workflow, and make sure uncertainty is never turned into a green light.

01Success
Successful response
Read the result, confidence, context and warnings. Store the response with its timestamp and version.
Your application should
Show the result with its confidence and any warnings.
Avoid
Drop the warnings or the confidence.
02Warning
Incomplete information
Treat as partial. Keep what was returned and record what is missing.
Your application should
Show “incomplete” and route the case for review.
Avoid
Show it as clear or as no risk.
03Notice
No relevant result
A valid response that found nothing to report. Record it with its timestamp and the sources it covered.
Your application should
Show “no relevant result found” with the coverage caveat.
Avoid
Present it as a guarantee of compliance.
04Error
Validation error
The request was not accepted. Do not retry unchanged. Fix the input, then resend.
Your application should
Tell the user which input to correct.
Avoid
Show a risk outcome.
05Error
Authentication failure
The credential was not accepted. Stop, and do not loop. Alert the owner of the integration.
Your application should
Show an access problem to an administrator.
Avoid
Retry in a tight loop, or fall back to a clear result.
06Warning
Rate or usage restriction
The call was limited. Wait, then retry within the documented policy.
Your application should
Show “temporarily limited” and queue the check.
Avoid
Skip the check and continue as if it passed.
07Unavailable
Service unavailable
No answer could be given. Retry with back-off and keep the item pending.
Your application should
Show “check pending” and hold the workflow.
Avoid
Treat an outage as a clear result.
08Warning
Version mismatch
The version you called differs from the one you built for. Stop, and compare against the version history.
Your application should
Flag to engineering and pause dependent decisions.
Avoid
Read fields as though nothing changed.

The rule for every state. Missing, partial, failed or unavailable information is never a clear result. Only a successful response can be read as a result, and even then it supports a decision and does not guarantee compliance. HTTP status codes and error formats shown as concepts here are confirmed in the documentation.

Illustrative handling guidance. Exact states, codes and formats are confirmed in the documentation.

REST and streaming concept

Two ways to receive risk signals.

The Risk & Compliance API delivers wallet, transaction, and sanctions risk signals over REST and streaming endpoints. The two suit different moments in your workflow. What each one offers in your deployment is confirmed during evaluation.

REST

Ask when you need to know

Request information when your workflow needs it
Receive an immediate structured response
Fits a check at a decision point, such as onboarding or a payment

Also confirm

Available endpointsConfirm in evaluation
Timeouts and status codesConfirm in evaluation

Streaming

Hear when something changes

Receive ongoing events or risk-signal changes
Fits a system that reacts to change rather than asking each time
Your application must handle events arriving late, twice or out of order

To confirm during evaluation

Streaming availabilityConfirm in evaluation
Delivery guaranteesConfirm in evaluation
RetriesConfirm in evaluation
Supported event typesConfirm in evaluation

Authentication and access

Secure access is a requirement to verify, not an assumption.

Ask about authentication, permission scope, usage limits, and access arrangements. No specific security method is claimed on this page. Each item below is an evaluation requirement.

Masked example, not a credentialFictional

# Nothing here is a real credential
Authorization: <credential> ••••••••••••••••
Environment: <sandbox | production>   # to confirm
Key ID:      ••••••••-••••

Never paste a real credential into a form, a chat or a screenshot on this website.
This website does not issue credentials. Request a demo, and the team will explain the access process.

API credentials
How credentials are issued, scoped and stored.
Evaluation requirement
Environment selection
Which environments exist, and how you choose between them.
Evaluation requirement
Role-based access
Who in your organization can create, view and revoke access.
Evaluation requirement
Credential rotation
How a credential is replaced without downtime.
Evaluation requirement
Request logging
What is logged for each request, and who can read it.
Evaluation requirement
Usage visibility
How you see your own usage and any limits.
Evaluation requirement
IP or network restrictions
Whether access can be limited to known networks.
Evaluation requirement

Developer experience

Continue to the documentation destination

API documentation and the customer application are hosted separately from this public website. The documentation covers authentication, endpoints, schemas, and usage limits, with full request and response examples.

API documentation Sign In

API documentation and the customer application are hosted separately from this public website.

API documentation
The full reference for the API.
Documented at docs
Authentication guide
How access and credentials work.
Documented at docs
Endpoint reference
Endpoints, schemas and usage limits.
Documented at docs
Request examples
Full request and response examples.
Documented at docs
Error handling
How failures are reported and handled.
Confirm in evaluation
Version history
How versions change over time.
Confirm in evaluation
Integration checklist
Steps to move from test to use.
Confirm in evaluation
Support route
Who to ask when something breaks.
Confirm in evaluation

Product verification

What needs confirmation

The Risk & Compliance API delivers wallet, transaction, and sanctions risk signals over REST and streaming endpoints, authenticated per environment with versioned schemas. Use these questions to confirm the details that matter for your evaluation.

Ask · 01
Available endpoints
Which endpoints exist for your use case?
Ask · 02
Request and response schemas
Where are the verified schemas and field definitions?
Ask · 03
Authentication method
How are calls authenticated, per environment?
Ask · 04
REST and streaming availability
Which delivery modes are available to you?
Ask · 05
Sandbox or test environment
Is there an environment for testing with fictional data?
Ask · 06
Rate and usage limits
What limits apply, and how are they communicated?
Ask · 07
Versioning policy
How do versions change, and how much notice is given?
Ask · 08
Error formats
How are failures and partial results reported?
Ask · 09
Logging and evidence
What can you log and keep as evidence?
Ask · 10
Support and access arrangements
How is access granted and who helps when it breaks?

These are evaluation questions, not guaranteed functionality. Answers depend on your deployment and are agreed with the team during your evaluation.

Before your demo

Risk & Compliance API: questions and answers

Where is the API documentation?

docs.fintraceintelligence.com. It covers authentication, endpoints, schemas, and usage limits.

Can I obtain an API key here?

No. This marketing website doesn’t issue credentials. Request a demo and the team will walk through the evaluation and access process.

Are code samples available on this page?

The example on this page is illustrative only. Full request and response examples are in the API documentation at docs.fintraceintelligence.com.

Continue your evaluation

Explore related product topics to build a broader evaluation. Risk context from the API can feed the decision workflow inside your own application.

Customer application
FinTrace API
Risk context
Customer decision workflow

Start a conversation

Discuss your API integration

Bring the application, the inputs, the outputs and the states it must handle.

Request Demo

API documentation

Define the contract before the connection.

Define required data

Choose the relevant risk signal

Submit an API request

Receive a structured response

Handle unavailable or uncertain results

Store evidence and continue

Inputs and outputs

Access and operating limits

Response handling

See what an integration conversation looks like.

Request

Response

Request

Response

Request

Response

Request

Response

Connection

Event payload

Know exactly what goes in and what comes back.

What your application sends

What your application receives

Design for every state, not just success.

Successful response

Incomplete information

No relevant result

Validation error

Authentication failure

Rate or usage restriction

Service unavailable

Version mismatch

Two ways to receive risk signals.

Secure access is a requirement to verify, not an assumption.

API credentials

Environment selection

Role-based access

Credential rotation

Request logging

Usage visibility

IP or network restrictions

Continue to the documentation destination

API documentation

Authentication guide

Endpoint reference

Request examples

Error handling

Version history

Integration checklist

Support route

Bring a scenario. Define what you want to learn.

Define the application use case

Identify required inputs

Select expected outputs

Choose request or streaming delivery

Define error handling

Confirm access requirements

Establish testing and rollout steps

What needs confirmation

Available endpoints

Request and response schemas

Authentication method

REST and streaming availability

Sandbox or test environment

Rate and usage limits

Versioning policy

Error formats

Logging and evidence

Support and access arrangements

Risk & Compliance API: questions and answers

Continue your evaluation

Wallet Screening

Entity Intelligence

Transaction Monitoring

Discuss your API integration

Your privacy choices