Skip to main content
API docs by Redocly

Tara - Payment Sanction Screening (PSS) (1.2.18.1)

Download OpenAPI specification:Download

URL: https://www.workfusion.com/digital-workers/tara-transaction-screening-analyst/

Transaction Screening or Payment Sanction Screening (PSS) Alert Disposition is the skill of the Digital Worker Tara. Tara is designed to identify real-time transactions or payments to or from sanctioned individuals, entities, or jurisdictions during on-boarding and throughout the customer relationship lifecycle that may pose a risk to financial institutions.

A request that reaches Tara answers with HTTP 200 and carries its outcome in the status field of the response body rather than in the HTTP status code: Tara sets COMPLETED when a decision was produced and INVALID_REQUEST when the message was rejected, and both are returned as 200. Failures raised by the Control Tower input connector before the request reaches Tara do use HTTP status codes, and answer with a body carrying only an error field: 401 when the bearer token is missing, malformed, or expired, and 404 when the signalId does not resolve to a deployed business process. The 400, 403, 500, and 504 statuses also come from the connector and carry that same error field, sometimes alongside a null requestId. The 502 and 503 statuses come from the proxy in front of the connector instead, so their bodies may not be JSON at all. The 5xx statuses are the only documented failures worth retrying, since every other one needs the request or the deployment corrected first.

Authentication is performed against a separate token service, which is not part of this API and has its own error contract, so its failures are not among the responses documented on the operations. They are described under the oauth security scheme.

Unknown properties in a request body are ignored, so a payload built for a newer or older schema is still accepted.

Authentication

Get an access token

Exchanges credentials for the bearer token that every other operation requires. This endpoint belongs to the identity service rather than to Tara, so it is served from a different host and its failures are not Tara or Control Tower responses. It is documented here so that integrators have the whole call sequence in one place. Both the host and the realm segment of the path are deployment-specific, so confirm them against your own environment rather than copying them from this page.

Request Body schema: application/x-www-form-urlencoded
grant_type
string

OAuth 2 grant type. The password grant is the flow this API documents.

username
string

Username of the service account the digital worker is called with.

password
string

Password for the account named in username.

client_id
string

Client configured for the realm in the identity service.

Responses

Response samples

Content type
application/json

Captured token response. The three token values are truncated here; the real ones are long JWTs. Send access_token as the bearer token on the other operations and read its lifetime from expires_in, in seconds. Both expires_in and refresh_expires_in come from the identity service configuration and differ between deployments, including which of the two is longer, so read them from the response rather than treating the values here as the durations you will see. Note that id_token is an OpenID Connect identity token rather than an API credential, so it is not the value those operations expect.

{
  • "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCIgOiA...",
  • "expires_in": 7200,
  • "refresh_expires_in": 2400,
  • "refresh_token": "eyJhbGciOiJSUzI1NiIsInR5cCIgOiA...",
  • "token_type": "Bearer",
  • "id_token": "eyJhbGciOiJSUzI1NiIsInR5cCIgOiA...",
  • "not-before-policy": 0,
  • "session_state": "81797fd8-d5fe-4e59-8753-ac2487461fa3",
  • "scope": "openid email profile"
}

Tara

Submit a payment message with screening alerts for Tara review

Submit a record for processing asynchronously. An acknowledgement that the message was added to the processing queue is returned immediately. Asynchronous execution is the most efficient way to process batches of records or a high volume of records.

Authorizations:
oauthbearer
path Parameters
signalId
required
string
Example: tara-pss-signal

Signal ID of the business process the record is sent to, as configured on the Data tab when streaming input is enabled.

Request Body schema: application/json

Alerts to be screened. The message id, the hit list, and a unique id on every hit are required; all other fields are optional. Unknown properties are ignored.

sourceSystemId
string

Source system number.

id
required
string

Message identification number.

type
string
Default: "PAYMENT_TRANSFER"

Payment message type.

subtype
string

Payment message subtype.

content
string

Optional if the content is already parsed with tagContent and tagType provided for each hit. Otherwise, required for parsing.

contentFormat
string
Enum: "FUF" "NATIVE" "SWIFT_MT" "SWIFT_MX" "SWIFT_NPP" "SWIFT_ADK"

Format of the screened message content, identifying the payment message standard the content was supplied in.

required
Array of objects (Hit)

Message hits. Message without hits will not be adjudicated.

object (PaymentInfo)

Payment details carried by the message, used as additional context during adjudication.

object

Any additional information, fields/values not specified elsewhere. Not used in processing but can be used in rules.

Responses

Request samples

Content type
application/json
Example

Only the required fields: a message id, and one hit carrying its own id. Everything else is optional.

{
  • "id": "9999991",
  • "type": "PAYMENT_TRANSFER",
  • "hits": [
    ]
}

Response samples

Content type
application/json

The record was accepted and queued. Poll check-record-status with the returned requestId, then fetch the decision from get-record-result once the status is COMPLETED.

{
  • "requestId": "3dbb99de-7556",
  • "status": "IN_PROGRESS",
  • "statusDetails": "Record Processing Started"
}

Check record processing status

Checks a record status based on the specified requestId. Returns the record processing status.

Authorizations:
oauthbearer
path Parameters
requestId
required
string
Example: 3dbb99de-7556

Control Tower request identifier returned by start-record-raw. Note this is not the identifier Tara reports inside the decision envelope.

Responses

Response samples

Content type
application/json
Example

Adjudication has not finished. Keep polling; no decision is available yet.

{
  • "requestId": "3dbb99de-7556",
  • "status": "IN_PROGRESS",
  • "format": "RAW"
}

Get a screening decision

Gets a screening decision based on the specified requestId. Returns the record results.

Authorizations:
oauthbearer
path Parameters
requestId
required
string
Example: 3dbb99de-7556

Control Tower request identifier returned by start-record-raw. Note this is not the identifier Tara reports inside the decision envelope.

Responses

Response samples

Content type
application/json
Example

Every hit decision is RESOLVE, so the message level suggestedAction is also RESOLVE, and the payment can be released without analyst review.

{
  • "requestId": "5e3eb0b9-2c84-4758-9b6c-76fe806ca310",
  • "status": "COMPLETED",
  • "statusDetails": "",
  • "decision": {
    },
  • "html_report_link": "https://example-workfusion.workfusion.io/reports/5e3eb0b9-2c84-4758-9b6c-76fe806ca310.html"
}

Process payment message with screening alerts

Process a record synchronously. This method returns a completed processing result. The response time of this method may deteriorate under high load, so please use the asynchronous version for higher volumes.

Authorizations:
oauthbearer
path Parameters
signalId
required
string
Example: tara-pss-signal

Signal ID of the business process the record is sent to, as configured on the Data tab when streaming input is enabled.

Request Body schema: application/json

Alerts to be screened. The message id, the hits, and a unique id on every hit are required; all other fields are optional. Unknown properties are ignored.

sourceSystemId
string

Source system number.

id
required
string

Message identification number.

type
string
Default: "PAYMENT_TRANSFER"

Payment message type.

subtype
string

Payment message subtype.

content
string

Optional if the content is already parsed with tagContent and tagType provided for each hit. Otherwise, required for parsing.

contentFormat
string
Enum: "FUF" "NATIVE" "SWIFT_MT" "SWIFT_MX" "SWIFT_NPP" "SWIFT_ADK"

Format of the screened message content, identifying the payment message standard the content was supplied in.

required
Array of objects (Hit)

Message hits. Message without hits will not be adjudicated.

object (PaymentInfo)

Payment details carried by the message, used as additional context during adjudication.

object

Any additional information, fields/values not specified elsewhere. Not used in processing but can be used in rules.

Responses

Request samples

Content type
application/json
Example

Only the required fields: a message id, and one hit carrying its own id. Everything else is optional.

{
  • "id": "9999991",
  • "type": "PAYMENT_TRANSFER",
  • "hits": [
    ]
}

Response samples

Content type
application/json
Example

Every hit decision is RESOLVE, so the message level suggestedAction is also RESOLVE, and the payment can be released without analyst review.

{
  • "requestId": "5e3eb0b9-2c84-4758-9b6c-76fe806ca310",
  • "status": "COMPLETED",
  • "statusDetails": "",
  • "decision": {
    },
  • "html_report_link": "https://example-workfusion.workfusion.io/reports/5e3eb0b9-2c84-4758-9b6c-76fe806ca310.html"
}