openapi: 3.0.0 externalDocs: description: Transaction Screening service on the Developer Hub url: 'https://developer.swift.com/api/transaction-screening-api/overview' info: version: v1.2.1 title: Transaction Screening Service contact: name: Developer Hub url: 'https://developer.swift.com' email: developer@swift.com license: name: API Restricted License url: 'https://developer.swift.com/api-license' description: |- The Transaction Screening service enables submitting batches of message screening requests and obtaining the outcome of the screening process, up to the decision taken by a user when a message was considered suspect and raised some alert. # Key concepts ## Screening request When the consumer wants to submit a message for screening it posts a screening request to the Transaction Screening service. That screening request embeds the message to screen (in base64) and further details. While the API model of the Screening Request is relatively flat, one can actually distinguish different kinds of attributes within the request, as shown in the diagram below: - Attributes that directly relate to the request such as its producer and identification, or how the Transaction Screening service will effectively have to process the request; - Attributes related to the message to screen, which includes the content of that message and a series of information about it; e.g. its business identifier (identifying the message in the sense defined by ISO 20022), its sending endpoint ("from" attribute). Note that the information at this level can also be present in the message content itself, depending on the format of message (e.g. a direction is present in the FIN MT message headers but it is not in a MX message). > ``` > Screening Request > {producer, identification, ...} > ↳ Message > {message_definition_identifier, business_message_identifier, from, ...} > ↳ Message Content > > ``` ## Screening request producer The producer concept is meant to allow segregation between different "producers" of screening requests of a __same__ institution subscribed to Transaction Screening; when retrieving screening results it acts as a filter, making it possible for a producer to only receive screening requests statuses for requests that it created. __Note:__ the producer therefore does not specify which institution the screening requests belongs to; this aspect is dictated by the consumer credentials only. The consumer can use the producer concept as it best suits its use case; e.g. - To enable entirely different back office systems submitting screening requests in the same institution while ensuring each is updated for the relevant statuses only; - To provide some affinity to a node when retrieving statuses when a back office system has multiple active nodes. ## Screening request identification The screening request identification unambiguously identifies the screening request of the producer that has created that request. This identification serves in the correlation of the screening request and the statuses showing the progress of the screening process. A producer therefore cannot submit several screening requests with the same identification; any duplicate identification will cause the rejection of the screening request. Additionally, - If a screening request, in a prior batch, was already accepted it remains valid; but when the duplicate screening requests are found within a same batch, all duplicates in that batch are rejected. - Even if a screening request was rejected (i.e. the Transaction Screening service responded with an ERRR status when it was posted), the identification must not be reused. - There is no time limitation to this constraint: identifications, even if they pertained to screening requests purged from the system, must not be reused. If necessary the producer can submit multiple screening requests for the same message instance (e.g. because the message has been corrected and needs to be rescreened, because the producer has lost prior screening results), provided that these are in screening requests carrying different identifications. Note that, since it is the same message instance, all these screening requests will likely have the same business message identifier. The notion of duplicate screening request identification only applies to one given producer. Different producers (i.e. with different producer_identification), even if submitting screening requests for the same institution, can use the same identifications without causing duplicates. ## Screening request status The screening request status represents the progress of request along the screening process. Depending on the scenario the trace of statuses can be as follows (where the first status PROC or ERRR represents that returned synchronously when creating the screening request; see below): - Message with no alert or non-blocking alert `PROC (processing)` → `CMPL (complete)` - Message with alert requiring a user decision `PROC (processing)` → `PEND (pending user decision)` → `CMPL (complete)` - Error during processing (e.g. message parsing or screening) `PROC (processing)` → `ERRR (error)` - Invalid screening request `ERRR (error)` ## Decision and reason Once the screening request has reached the status CMPL (complete) the decision represents the outcome of the screening process. This decision is assorted with a reason motivating it. The combinations below of decisions and reasons can be returned by the Transaction Screening service. The Transaction Screening API Usage Guidelines (see the documentation on the Developer Hub and SWIFT Knowledge Centre) clarify the effective usage of the decision and reason by the Transaction Screening service. - `ALLO (allow)` + `NOSC (not screened)`, `NOAL (no alert)`, `NBLA (non-blocking alert)` or `USER (user decision)` - `BLOK (block)` + `USER (user decision)` - `NONE (none)` + `TMOU (timeout)` # Using the Transaction Screening Service ## Sending Screening Requests Screening requests are submitted by a producer to the Transaction Screening service in batches (see limit of batch size in the API specification). For performance reasons and to avoid call rejection due to spike arresting and rate limitations, the consumer is encouraged to constitute batches of reasonable size rather than posting screening requests individually. If the POST request body is properly formatted (i.e. it respects the API specification), the Transaction Screening service will, 1. Acknowledge the creation of some screening request resources (once for the whole POST) with an HTTP status code 201; 2. Provide, for each screening request within the POST, a status indicating if it was created in - A PROC (processing) status because the request was properly formed and accepted; - Or an ERRR (error) status due to some failure (in such a case an error structure is also included to help pinpointing the issue). A batch can be partially accepted (i.e. the POST response can include a mix of PROC and ERRR statuses). Because of this the Transaction Screening service will not return an HTTP status code 400 when there is an error with a screening request. The consumer must review the status returned for each request to know which are accepted. A screening request in status PROC will be processed asynchronously; its status will be monitored with the GET operation (see next section). A batch of screening requests can mix messages of different formats; e.g. a batch can contain requests for both MT and MX messages. ## Polling the Status of Screening Requests The Transaction Screening service supports a polling model enabling screening request producers to be updated with the progress of their screening requests (via the GET operation). Several variants, below, are provided to enable the consumer getting the right statuses in a stateless way; the variants are mutually exclusive. - Sequence number based GET filter: sequence_number The Transaction Screening service stamps each status created during the screening process with a "sequence number". By disclosing relevant sequence numbers to the consumer and letting it use them in the GET operation the Transaction Screening services can determine what statuses were not yet communicated to the consumer. Practically, with each response to a GET call, the Transaction Screening service provides a new sequence number (along with the statuses) to enable obtaining, in a next query, more recent statuses than those already returned. The sequence number returned with the response ensures that there is no gap in the sequence returned by the service and that no status is returned more than once. This is illustrated in the following sequence of GET calls: GET request ?sequence_number=0 ⇢ GET response {sequence_number: 87407, statuses: [...]} GET request ?sequence_number=87407 ⇢ GET response {sequence_number: ..., statuses: [...]} ... The series of GET calls can be bootstrapped by - Obtaining a sequence number with the date and time based variant below. The sequence number returned in that case will ensure that there is no gap or overlap between the statuses obtained by calling the two variants successively. - Using the special sequence number "0" representing a point in time anterior to any status of any screening request of the producer (shown in the figure above). Calling the GET operation several times with the same sequence number will return - The same statuses each time; - Possibly additional newer statuses if some were created in between the calls due to the progress of some screening requests. Also note that since this variant intends to keep the consumer updated with the actual progress of the screening requests - The status PROC (processing) is never returned in this case, as it is of no use to the consumer (the initial POST confirms the screening request is accepted and will be processed). Only subsequent statuses in the diagram above can be returned. - When the screening request raises an alert PEND (pending user decision) is only returned **once**. The next status returned by the GET operation for the particular screening request will indicate its completion (see screening request status transitions above). - Date and time based GET filter: last_update The producer intends to retrieve all the statuses updated at, or after, a timestamp known from the producer. Since there is a limit on the number of statuses returned in one call it is possible that the consumer will need to perform other calls with more recent timestamps to be fully up-to-date. Depending on the situation, determining a timestamp that creates no gap in the sequence and that will not cause the same status to be returned multiple times can be tricky (e.g. because the clocks of the consumer and the service provider are not necessarily synchronous). Alternatively, after a call with a timestamp, the consumer can switch to the variant based on the sequence number (above); a sequence number is also included with the results of a date and time based query to enable this. Similarly to the variant above the status PROC (processing) will not be returned. - Specific screening requests GET filter: identification_list (array) When explicitly querying some screening requests, by filtering on their identification, the Transaction Screening service returns the latest status of these requests. It is meant to be used in error recovery scenarios or e.g. when the consumer needs to check if a particular screening request has been submitted (no status will be returned if the screening request is unknown). Unlike the variants above the status PROC (processing) can be returned if the screening request has not progressed. ### Recovering from a Consumer Failure Note: this section discusses a failure of the service consumer application, not errors associated with invalid screening requests or messages. See references to the ERRR (error) status in this documentation for details about the latter cases. The consumer is advised to persist the sequence number value along with the screening request statuses in a transactional manner, so that even if a failure (of the consumer) occurs the GET sequence can restart with a sequence number guaranteeing no status will omitted. Although, when that is not possible (for reasons that solely depend on the consumer), we recommend making a first GET call with the date and time based variant after recovering from the failure. The last_update query parameter can be set to a value that slightly precedes the moment of failure to ensure no status is skipped. The consumer then discards any duplicate status that it would have processed already. Alternatively, the bootstrap sequence number 0 can be used (see above). The Transaction Screening service will then return the sequence progression for **all** the screening requests it has received from the producer (and that were not yet cleaned according to the data retention policies applying to the service). Obtaining the statuses up to the moment of failure can require multiple GET calls, as the size of the response is limited. # Complement to Model Documentation Due to restrictions in the OpenAPI standard, it is not possible to provide a description for attributes referencing a data type from the model. The list below complements the documentation with the missing descriptions. The tag **[guidelines]** indicates that the attribute is subject to mandatory or recommended values described in the Transaction Screening API Usage Guidelines (see the documentation on the Developer Hub and SWIFT Knowledge Centre). For readers familiar with ISO 20022 an [ISO20022] tag is displayed with an additional pointer to highlight that the attribute refers to a concept present in ISO 20022. - `ScreeningRequests` Collects a batch of screening requests. - `producer_identification` Specifies the identification of the application instance that produced the batch of screening requests. - `screening_requests` Provides the screening requests in the batch. - `ScreeningRequest` Requests the screening of a message to the Transaction Screening service. - `identification` Unambiguously identifies the screening request of the producer that has created that request. The identification is used to correlate the request and the statuses giving the progress of that request. *Usage note:* The first 8 characters of the identification must be the YYYYMMDD date part of the current time in UTC without timezone offset. The Transaction Screening service will tolerate some deviation to cope with request transmission delays or minor clock de-synchronisation. The consumer can freely define the rest of the identification. - `owner` The attribute is reserved and must be omitted. - `routing` **[guidelines]** Specifies a code that can be used in routing rules in the Transaction Screening service. - `business_message_identifier` **[guidelines]** Unambiguously identifies the business message to the messaging endpoint that has created the business message. *[ISO20022] Business Application Header / Business Message Identifier (BizMsgIdr)* - `message_definition_identifier` **[guidelines]** Contains the message identifier that defines the business message in the message_content attribute. *[ISO20022] Business Application Header / Message Definition Identifier (MsgDefIdr)* - `business_service` **[guidelines]** Specifies the business service agreed between the two MessagingEndpoints under which rules this Business Message is exchanged. *[ISO20022] Business Application Header / Business Service (BizSvc)* - `from`, `to` **[guidelines]** Specifies the MessagingEndpoints exchanging the Business Message. *[ISO20022] Business Application Header / From (Fr), To (To)* - `message_direction` **[guidelines]** Specifies the direction of the message assuming that the institution owning the screening request for that message is the sending or the receiving endpoint. - `message_content` Contains the base64 encoded content of the business message to be screened. - `ScreeningRequestStatuses` Collects statuses of one or more of screening requests. - `producer_identification` Indicates which producer has created the screening requests for which the statuses are given. *Usage note:* The producer identification returned by the Transacion Screening service (whether it is when creating screening requests or polling for statuses) is necessarily the same as that in the consumer request. - `sequence_number` Identifies the point in time (in a way that is understandable by the service provider) at which the most recent status in the collection was created. No assumption should be made on the format or values. It is meant to be passed as-is in sequence of operations to retrieve only statuses created past that point in time. *Usage note:* The attribute is only present in response to operation retrieving screening request statuses when variant with parameters sequence_number or last_update have been used. - `status` Provides the screening requests statuses in the collection. *Usage note:* When retrieving screening request statuses the array can be empty if the filter parameter are such that no status is retrieved. This includes the normal case where no screening request has progressed since the point in time identified by the sequence_number or last_update parameters, or if the screening request identification_list parameter does not refer to an existing screening request. None of the variants retrieving screening request statuses will report statuses for requests declared invalid upon POST (i.e. for which the POST response included a status ERRR). When querying statuses using a point in time the collection of statuses possibly includes several statuses for the same screening request if it transitioned to different statuses since that point in time. While the consumer should not make any assumption on the order of the statuses of different screening requests, statuses of a same screening request are guaranteed to be in order of increasing last update time (therefore following the logical order in the screening process). When querying statuses for specific screening requests (i.e. by identification_list) only the current status is returned. - `ScreeningRequestStatus` Provides information about the status of a request along the screening process, and the outcome where relevant. - `identification` Identifies the screening request for which the status is provided. - `last_update` Indicates when the particular status was created or last updated. - `status` Indicates the status of the request in the screening process. - `decision` When the status code is COMPL, provides the outcome of the screening process, including the decision to be applied to the message. Attribute decision is mutually exclusive with error. - `error` When the status code is ERR, provides details about the error condition. Attribute error is mutually exclusive with decision. - `ScreeningDecision` **[guidelines]** Provides the outcome of the screening process, including the decision to be applied to the message. - `decision` Indicates what decision must be applied to the message. This decision is a result of automated or user actions, depending on settings in the Transaction Screening service, and whether the screening caused an alert or not. - `reason` Indicates what reason motivated the decision. servers: - description: Production environment url: https://api.swiftnet.sipn.swift.com/swift-tss-api/v1 - description: Test environment url: https://api-test.swiftnet.sipn.swift.com/swift-tss-api-pilot/v1 - description: Sandbox environment url: https://sandbox.swift.com/swift-tss-api/v1 paths: /screening-requests: post: tags: - screening-requests summary: Submits a batch of screening requests. description: >- Submits a batch of screening requests to the Transaction Screening Service. If accepted (as indicated by a status for each request in the response) these requests will be processed asynchronously; their progress can be observed with the GET operation. operationId: ScreeningRequestsPost requestBody: content: application/json: schema: $ref: '#/components/schemas/ScreeningRequests1Resource' examples: UseCase1: $ref: '#/components/examples/UseCase1-ScreeningRequest' UseCase2: $ref: '#/components/examples/UseCase2-ScreeningRequest' UseCase3: $ref: '#/components/examples/UseCase3-ScreeningRequest' UseCase4: $ref: '#/components/examples/UseCase4-ScreeningRequest' UseCase5: $ref: '#/components/examples/UseCase5-ScreeningRequest' description: >- Batch of screening requests submitted to the Transaction Screening Service. required: true responses: '201': description: Resource created. content: application/json: schema: $ref: '#/components/schemas/ScreeningRequestStatuses1Resource' examples: UseCase1: $ref: '#/components/examples/UseCase1-ScreeningRequest-Response' UseCase2: $ref: '#/components/examples/UseCase2-ScreeningRequest-Response' UseCase3: $ref: '#/components/examples/UseCase3-ScreeningRequest-Response' UseCase4: $ref: '#/components/examples/UseCase4-ScreeningRequest-Response' UseCase5: $ref: '#/components/examples/UseCase5-ScreeningRequest-Response' '400': description: Bad Request content: application/json: schema: $ref: '#/components/schemas/GenericStatus1' api_request_is_malformed: examples: response: value: code: SwAP501 severity: FATL text: API request is malformed. '401': description: 'Unauthorized WWW-Authenticate: Bearer realm=''SwAP''' content: application/json: schema: $ref: '#/components/schemas/GenericStatus1' invalid_token: examples: response: value: severity: FATL code: SwAP502 text: Invalid OAuth token. insufficient_scope: examples: response: value: severity: FATL code: SwAP503 text: >- OAuth access token has insufficient scope for the requested service. '404': description: Not Found content: application/json: schema: $ref: '#/components/schemas/GenericStatus1' invalid_request: examples: response: value: severity: FATL code: SwAP506 text: Invalid request. Resource does not exist. service_not_provisioned: examples: response: value: severity: FATL code: SwAP506 text: API service not provisioned. '429': description: Too many requests content: application/json: schema: $ref: '#/components/schemas/GenericStatus1' too_many_requests: examples: response: value: severity: TRAN code: SwAP507 text: >- Request cannot be processed at this time. Please try again. '500': description: Internal Server Error content: application/json: schema: $ref: '#/components/schemas/GenericStatus1' '502': description: Bad Gateway content: application/json: schema: $ref: '#/components/schemas/GenericStatus1' '503': description: Service Unavailable content: application/json: schema: $ref: '#/components/schemas/GenericStatus1' service_unavailable: examples: response: value: severity: TRAN code: SwAP590 text: Service is temporarily unavailable. Please try later. '504': description: Gateway Timeout content: application/json: schema: $ref: '#/components/schemas/GenericStatus1' service_timeout: examples: response: value: severity: TRAN code: SwAP591 text: Service provider timeout. Please try later. default: description: Unexpected error content: application/json: schema: $ref: '#/components/schemas/GenericStatus1' /screening-requests/statuses: get: tags: - screening-requests summary: Retrieves the statuses of screening requests. description: >- Retrieves the statuses of screening requests previously submitted to, and accepted by, the Transaction Screening Service. The sequence_number, last_update and identification_list enable filtering the statuses of interest; one and only one of these parameter is required. operationId: ScreeningRequestsGet parameters: - in: query name: producer_identification required: true description: >- Identifies the producer of the screening requests for which the statuses must be obtained. schema: $ref: '#/components/schemas/Max15AlphaNumericText' example: BOAPPL0001 - in: query name: sequence_number required: false description: >- Specifies the point in time, in the form of a sequence number, after which the caller is interested in obtaining screening request statuses. A sequence number is obtained as a result of a GET operation (with a sequence_number or with a last_update timestamp parameter) and enable calling that operation again to obtain the next round of statuses (if any). schema: $ref: '#/components/schemas/Max50Text' examples: UseCase1-Status-a: summary: Use case 1.a. Bootstrap status retreival using sequence number 0. value: "0" UseCase1-Status-b: summary: Use case 1.b. Retrieve statuses using sequence number obtained with a previous call. value: "1234" - in: query name: last_update required: false description: >- Specifies the point in time, in the form of an ISODateTime timestamp, at which, or after which, the caller is interested in obtaining screening request statuses. A sequence number is provided along with the results to enable querying the next round of statuses directly following those in the response. schema: $ref: '#/components/schemas/ISODateTime' example: '2019-04-15T13:33:00.000Z' - in: query name: identification_list required: false description: >- Explicitly specifies a list of screening requests for which the most recent statuses must be obtained. style: form schema: type: array items: $ref: '#/components/schemas/Max50TextWithDatePrefix' minItems: 1 uniqueItems: true example: - 20190417.UseCase1Message1 - 20190417.UseCase2Message2 responses: '200': description: Provides the status for a specific set of screening messages. content: application/json: schema: $ref: '#/components/schemas/ScreeningRequestStatuses1Resource' examples: UseCase-1a: $ref: '#/components/examples/UseCase1-Status-a-Response' UseCase-1b: $ref: '#/components/examples/UseCase1-Status-b-Response' UseCase-1c: $ref: '#/components/examples/UseCase1-Status-c-Response' UseCase-1d: $ref: '#/components/examples/UseCase1-Status-d-Response' UseCase-1e: $ref: '#/components/examples/UseCase1-Status-e-Response' UseCase-1f: $ref: '#/components/examples/UseCase1-Status-f-Response' UseCase-5: $ref: '#/components/examples/UseCase5-Status-Response' '400': description: Bad Request content: application/json: schema: $ref: '#/components/schemas/GenericStatus1' api_request_is_malformed: examples: response: value: code: SwAP501 severity: FATL text: API request is malformed. '401': description: 'Unauthorized WWW-Authenticate: Bearer realm=''SwAP''' content: application/json: schema: $ref: '#/components/schemas/GenericStatus1' invalid_token: examples: response: value: severity: FATL code: SwAP502 text: Invalid OAuth token. insufficient_scope: examples: response: value: severity: FATL code: SwAP503 text: >- OAuth access token has insufficient scope for the requested service. '404': description: Not Found content: application/json: schema: $ref: '#/components/schemas/GenericStatus1' invalid_request: examples: response: value: severity: FATL code: SwAP506 text: Invalid request. Resource does not exist. service_not_provisioned: examples: response: value: severity: FATL code: SwAP506 text: API service not provisioned. '429': description: Too many requests content: application/json: schema: $ref: '#/components/schemas/GenericStatus1' too_many_requests: examples: response: value: severity: TRAN code: SwAP507 text: >- Request cannot be processed at this time. Please try again. '500': description: Internal Server Error content: application/json: schema: $ref: '#/components/schemas/GenericStatus1' '502': description: Bad Gateway content: application/json: schema: $ref: '#/components/schemas/GenericStatus1' '503': description: Service Unavailable content: application/json: schema: $ref: '#/components/schemas/GenericStatus1' service_unavailable: examples: response: value: severity: TRAN code: SwAP590 text: Service is temporarily unavailable. Please try later. '504': description: Gateway Timeout content: application/json: schema: $ref: '#/components/schemas/GenericStatus1' service_timeout: examples: response: value: severity: TRAN code: SwAP591 text: Service provider timeout. Please try later. default: description: Unexpected error content: application/json: schema: $ref: '#/components/schemas/GenericStatus1' components: securitySchemes: oauthBearerToken: type: http scheme: bearer bearerFormat: opaque OAuth 2.0 description: >- The access token obtained as a result of OAuth 2.0 JWT Bearer Token Flow - RFC 7523. Please visit [SWIFT OAuth Token API](https://developer.swift.com/swift-oauth-token-api) for more information and examples. In this declaration only the basic security element to transport the bearer token of an OAuth2 process is declared. schemas: ScreeningRequests1Resource: type: object description: Collects a batch of screening requests. additionalProperties: false properties: producer_identification: $ref: '#/components/schemas/Max15AlphaNumericText' screening_requests: type: array maxItems: 100 description: Provides the screening requests in the collection. items: $ref: '#/components/schemas/ScreeningRequest1' required: - screening_requests - producer_identification Max15AlphaNumericText: type: string description: Specifies an alphanumeric string with a maximum length of 15 characters. minLength: 1 maxLength: 15 pattern: '^[a-zA-Z0-9]{1,15}$' ScreeningRequest1: type: object description: >- Requests the screening of a message to the Transaction Screening Service. additionalProperties: false properties: identification: $ref: '#/components/schemas/Max50TextWithDatePrefix' owner: $ref: '#/components/schemas/AnyBICDec2014Identifier' routing: $ref: '#/components/schemas/Max15AlphaNumericText' business_message_identifier: $ref: '#/components/schemas/Max35Text' message_definition_identifier: $ref: '#/components/schemas/Max35Text' business_service: $ref: '#/components/schemas/Max35Text' from: $ref: '#/components/schemas/AnyBICDec2014Identifier' to: $ref: '#/components/schemas/AnyBICDec2014Identifier' message_direction: $ref: '#/components/schemas/MessageDirection1Code' message_content: type: string format: base64 required: - identification - business_message_identifier - message_definition_identifier - message_content Max50TextWithDatePrefix: type: string description: Specifies a character string with a maximum length of 50 characters where the 8 first characters represent a date formatted as YYYYMMDD. pattern: >- ^(?:[1-9]\d{3}(?:(?:0[1-9]|1[0-2])(?:0[1-9]|1\d|2[0-8])|(?:0[13-9]|1[0-2])(?:29|30)|(?:0[13578]|1[02])31)|(?:[1-9]\d(?:0[48]|[2468][048]|[13579][26])|(?:[2468][048]|[13579][26])00)0229)[A-Za-z0-9_\-\.:]{1,42}$ AnyBICDec2014Identifier: type: string description: >- Code allocated to a financial or non-financial institution by the ISO 9362 Registration Authority, as described in ISO 9362: 2014 - "Banking - Banking telecommunication messages - Business identifier code (BIC)". pattern: '^[A-Z0-9]{4,4}[A-Z]{2,2}[A-Z0-9]{2,2}([A-Z0-9]{3,3}){0,1}$' Max35Text: type: string description: Specifies a character string with a maximum length of 35 characters. minLength: 1 maxLength: 35 Max50Text: type: string description: Specifies a character string with a maximum length of 50 characters. minLength: 1 maxLength: 50 MessageDirection1Code: type: string description: Specifies the direction of a message. enum: - RECE - SENT ScreeningRequestStatuses1Resource: type: object description: Collects statuses of one or more of screening requests. additionalProperties: false properties: producer_identification: $ref: '#/components/schemas/Max15AlphaNumericText' sequence_number: $ref: '#/components/schemas/Max50Text' status: type: array maxItems: 100 description: Provides the statuses in the collection. items: $ref: '#/components/schemas/ScreeningRequestStatus1' required: - producer_identification - status ScreeningRequestStatus1: type: object description: >- Provides information about the status of a request in the screening process, and the outcome where relevant. additionalProperties: false properties: identification: $ref: '#/components/schemas/Max50TextWithDatePrefix' last_update: $ref: '#/components/schemas/ISODateTime' status: $ref: '#/components/schemas/ScreeningStatus1Code' error: $ref: '#/components/schemas/GenericStatus1' decision: $ref: '#/components/schemas/ScreeningDecision1' required: - identification - last_update - status ISODateTime: type: string description: >- A particular point in the progression of time defined by a mandatory date and a mandatory time component, expressed in either UTC time format (YYYY-MM-DDThh:mm:ss.sssZ), local time with UTC offset format (YYYY-MM-DDThh:mm:ss.sss+/-hh:mm), or local time format (YYYY-MM-DDThh:mm:ss.sss). These representations are defined in "XML Schema Part 2: Datatypes Second Edition - W3C Recommendation 28 October 2004" which is aligned with ISO 8601. Note on the time format: 1) beginning / end of calendar day 00:00:00 = the beginning of a calendar day 24:00:00 = the end of a calendar day 2) fractions of second in time format Decimal fractions of seconds may be included. In this case, the involved parties shall agree on the maximum number of digits that are allowed. pattern: >- ^(?:[1-9]\d{3}-(?:(?:0[1-9]|1[0-2])-(?:0[1-9]|1\d|2[0-8])|(?:0[13-9]|1[0-2])-(?:29|30)|(?:0[13578]|1[02])-31)|(?:[1-9]\d(?:0[48]|[2468][048]|[13579][26])|(?:[2468][048]|[13579][26])00)-02-29)T(?:[01]\d|2[0-3]):[0-5]\d:[0-5]\d(?:\.[0-9]+)?(?:Z|[+-][01]\d:[0-5]\d)?$ ScreeningStatus1Code: type: string description: >- Describes the status of a request in the screening process: * `PROC`: Request is being processed by the service (it is the initial status of a request when it is accepted); * `PEND`: Request is pending user action; * `CMPL`: Screening is complete, including any user action; * `ERRR`: Request is erroneous and could not be processed successfully. enum: - CMPL - ERRR - PEND - PROC ScreeningDecision1: type: object description: >- Provides the outcome of the screening process, including the decision to be applied to the message. additionalProperties: false properties: decision: $ref: '#/components/schemas/ScreeningDecision1Code' reason: $ref: '#/components/schemas/ScreeningReason1Code' required: - decision - reason ScreeningDecision1Code: type: string description: >- Describes the decision to be applied to a message as a result of the screening process: * `ALLO`: Message is allowed to continue along the normal flow; * `BLOK`: Message must be blocked; * `NONE`: Although the screening process completed, no decision was taken due to exceptional circumstances. enum: - ALLO - BLOK - NONE ScreeningReason1Code: type: string description: >- Describes the reason motivating a decision to be a applied to a message: * `NOSC`: The message was not screened, as required by the routing configuration applying to the screening request; * `NOAL`: The message was screened but caused no alert; * `NBLA`: The message was screened but only caused a non-blocking alert; * `USER`: The message was screened, caused a blocking alert and a user took the decision; * `TMOU`: The message was screened and caused a blocking alert but a user failed to take a decision within the prescribed delay and a timeout occurred. enum: - USER - TMOU - NOSC - NBLA - NOAL GenericStatus1: type: object description: >- Specifies the generic status as a result of a method applied to a Resource. additionalProperties: false properties: code: $ref: '#/components/schemas/Max35Text' severity: $ref: '#/components/schemas/ErrorSeverity2Code' text: $ref: '#/components/schemas/Max256Text' user_message: $ref: '#/components/schemas/Max256Text' more_info: $ref: '#/components/schemas/Max256Text' required: - code - severity ErrorSeverity2Code: type: string description: Indicates the severity of the error code. enum: - TRAN - LOGI - FATL Max256Text: type: string description: Specifies a character string with a maximum length of 256 characters. minLength: 1 maxLength: 256 examples: UseCase1-ScreeningRequest: summary: Use case 1. Submit screening request for one MT 199 message. value: producer_identification: BOAPPL0001 screening_requests: - identification: 20190417.UseCase1Message1 business_message_identifier: 20190417-123 message_definition_identifier: fin.199.2020 message_content: >- ezE6RjAxQUJDREJFMTFYWFhYOTk5OTk5OTk5OX17MjpJMTk5U1dIUUJFQkJYWFhYTn17Mzp7MTA4OjEyMzQ1Njc4OTN9fXs0Og0KOjIwOjIwMTkwNDE3LTEyMw0KOjc5OlRlc3QgbWVzc2FnZQ0KLX17Uzp7U0FDOn17Q09QOlB9fQ== UseCase1-ScreeningRequest-Response: summary: Use case 1. Request to screen the message is accepted. Status is processing while the message is being screened asynchronously. value: producer_identification: BOAPPL0001 status: - identification: 20190417.UseCase1Message1 last_update: '2021-04-17T14:35:11.000Z' status: PROC UseCase2-ScreeningRequest: summary: Use case 2. Submit screening requests for one MT 199 and one MT 103 messages. Identification UseCase1Message1 is reused from UseCase1 to highlight behaviour in case of duplicate request. value: producer_identification: BOAPPL0001 screening_requests: - identification: 20190417.UseCase1Message1 business_message_identifier: '20190417-123' message_definition_identifier: fin.199.2020 message_content: >- ezE6RjAxQUJDREJFMTFYWFhYOTk5OTk5OTk5OX17MjpJMTk5U1dIUUJFQkJYWFhYTn17Mzp7MTA4OjEyMzQ1Njc4OTN9fXs0Og0KOjIwOjIwMTkwNDE3LTEyMw0KOjc5OlRlc3QgbWVzc2FnZQ0KLX17Uzp7U0FDOn17Q09QOlB9fQ== - identification: 20190417.UseCase2Message2 business_message_identifier: '394882' message_definition_identifier: fin.103.2020 message_content: >- ezE6RjAxQUFBQUJFQkJBWFhYMTIzNDAxMjM0NX17MjpPMTAzMTUxMTE5MDYwNkNDQ0NVUzMzR1hYWDAwMDAwMTMwODUxOTA1MTQxMTQ5U317Mzp7MTA4OlVIQk1UMTAzMDA0fXsxMjE6ZDg1YTc1NzQtODYzYS00OTRkLWJmYmUtNDA4NGJmNzcwNGUxfX17NDoNCjoyMDozOTQ4ODINCjoyM0I6Q1JFRA0KOjIzRTpQSE9CLzIwLjUyNy4xOS42MA0KOjMyQToxOTA4MjhVU0QxMTIxLDUwDQo6MzNCOlVTRDExMjEsNTANCjo1MEY6Lzk0MjI2Nzg5MA0KMS9EUiBCQU5LDQoyL01BSU4gU1QsIDEyMw0KMy9BVC9WSUVOTkENCjo1M0E6RERERFVTMzMNCjo1NEE6QkJCQkdCMjINCjo1OTovNzIzNDkxNTI0DQpDUiBCQU5LDQpCT1VMRVZBUkQgMTIzDQpBTVNURVJEQU0NCjo3MUE6U0hBDQotfQ== UseCase2-ScreeningRequest-Response: summary: Use case 2. Request to screen message identified by UseCase1Message1 is rejected because the identification was already used in a previous request. The request for the other message is accepted. Status is processing while the latter message is being screened asynchronously. value: producer_identification: BOAPPL0001 status: - identification: 20190417.UseCase1Message1 last_update: '2021-04-17T14:35:11.000Z' status: ERRR error: code: TSS.SRQ0001 severity: FATL text: Duplicate screening request identifier user_message: If the problem persists, please contact support. - identification: 20190417.UseCase2Message2 last_update: '2021-04-17T14:35:11.000Z' status: PROC UseCase3-ScreeningRequest: summary: Use case 3. Submit screening requests for two pacs.008 MX messages, one with a Business Application Header and one without. value: producer_identification: BOAPPL0001 screening_requests: - identification: 20190417.UseCase3Message1 business_message_identifier: 'BBBB/200227-PSR/001' message_definition_identifier: pacs.008.001.08 business_service: swift.cbprplus.01 message_direction: RECE message_content: >- PGhlYWQ6QXBwSGRyIHhtbG5zOmhlYWQ9InVybjppc286c3RkOmlzbzoyMDAyMjp0ZWNoOnhzZDpoZWFkLjAwMS4wMDEuMDIiPg0KCTxoZWFkOkZyPg0KCQk8aGVhZDpGSUlkPg0KCQkJPGhlYWQ6RmluSW5zdG5JZD4NCgkJCQk8aGVhZDpCSUNGST5CQU5LQkVBQVlZWTwvaGVhZDpCSUNGST4NCgkJCTwvaGVhZDpGaW5JbnN0bklkPg0KCQk8L2hlYWQ6RklJZD4NCgk8L2hlYWQ6RnI+DQoJPGhlYWQ6VG8+DQoJCTxoZWFkOkZJSWQ+DQoJCQk8aGVhZDpGaW5JbnN0bklkPg0KCQkJCTxoZWFkOkJJQ0ZJPkJBTktCRUJCWlpaPC9oZWFkOkJJQ0ZJPg0KCQkJPC9oZWFkOkZpbkluc3RuSWQ+DQoJCTwvaGVhZDpGSUlkPg0KCTwvaGVhZDpUbz4NCgk8aGVhZDpCaXpNc2dJZHI+c3dpZnQuY2JwcnBsdXM8L2hlYWQ6Qml6TXNnSWRyPg0KCTxoZWFkOk1zZ0RlZklkcj5wYWNzLjAwOC4wMDEuMDg8L2hlYWQ6TXNnRGVmSWRyPg0KCTxoZWFkOkNyZUR0PjIwMjAtMDItMjdUMTc6NTA6MDArMDA6MDA8L2hlYWQ6Q3JlRHQ+DQo8L2hlYWQ6QXBwSGRyPg0KPHBhY3M6RG9jdW1lbnQgeG1sbnM6cGFjcz0idXJuOmlzbzpzdGQ6aXNvOjIwMDIyOnRlY2g6eHNkOnBhY3MuMDA4LjAwMS4wOCI+DQoJPHBhY3M6RklUb0ZJQ3N0bXJDZHRUcmY+DQoJCTxwYWNzOkdycEhkcj4NCgkJCTxwYWNzOk1zZ0lkPkJCQkIvMjAwMjI3LVBTUi8wMDE8L3BhY3M6TXNnSWQ+DQoJCQk8cGFjczpDcmVEdFRtPjIwMjAtMDItMjdUMTc6NTA6MDArMDA6MDA8L3BhY3M6Q3JlRHRUbT4NCgkJCTxwYWNzOk5iT2ZUeHM+MTwvcGFjczpOYk9mVHhzPg0KCQkJPHBhY3M6U3R0bG1JbmY+DQoJCQkJPHBhY3M6U3R0bG1NdGQ+SU5EQTwvcGFjczpTdHRsbU10ZD4NCgkJCTwvcGFjczpTdHRsbUluZj4NCgkJPC9wYWNzOkdycEhkcj4NCgkJPHBhY3M6Q2R0VHJmVHhJbmY+DQoJCQk8cGFjczpQbXRJZD4NCgkJCQk8cGFjczpJbnN0cklkPk1NTU0vMjAwMjI3PC9wYWNzOkluc3RySWQ+DQoJCQkJPHBhY3M6RW5kVG9FbmRJZD5SRUZFUkVOQ0UwMDAyPC9wYWNzOkVuZFRvRW5kSWQ+DQoJCQkJPHBhY3M6VUVUUj5iNzYyZDNmMS02ZDkwLTQzNDctYTdmMi0yYjgxNDhiZjQ3ZjQ8L3BhY3M6VUVUUj4NCgkJCTwvcGFjczpQbXRJZD4NCgkJCTxwYWNzOkludHJCa1N0dGxtQW10IENjeT0iRVVSIj4xMDAuMDwvcGFjczpJbnRyQmtTdHRsbUFtdD4NCgkJCTxwYWNzOkludHJCa1N0dGxtRHQ+MjAyMC0wMi0yODwvcGFjczpJbnRyQmtTdHRsbUR0Pg0KCQkJPHBhY3M6SW5zdGRBbXQgQ2N5PSJFVVIiPjEwMC4wPC9wYWNzOkluc3RkQW10Pg0KCQkJPHBhY3M6Q2hyZ0JyPlNIQVI8L3BhY3M6Q2hyZ0JyPg0KCQkJPHBhY3M6RGJ0cj4NCgkJCQk8cGFjczpObT5EUiBCQU5LPC9wYWNzOk5tPg0KCQkJCTxwYWNzOlBzdGxBZHI+DQoJCQkJCTxwYWNzOkFkckxpbmU+TUFJTiBTVCwgMjAwMDwvcGFjczpBZHJMaW5lPg0KCQkJCQk8cGFjczpBZHJMaW5lPkFudHdlcnBlbiwgQkU8L3BhY3M6QWRyTGluZT4NCgkJCQk8L3BhY3M6UHN0bEFkcj4NCgkJCTwvcGFjczpEYnRyPg0KCQkJPHBhY3M6RGJ0ckFndD4NCgkJCQk8cGFjczpGaW5JbnN0bklkPg0KCQkJCQk8cGFjczpCSUNGST5CQU5LQkVBQVlZWTwvcGFjczpCSUNGST4NCgkJCQk8L3BhY3M6RmluSW5zdG5JZD4NCgkJCTwvcGFjczpEYnRyQWd0Pg0KCQkJPHBhY3M6Q2R0ckFndD4NCgkJCQk8cGFjczpGaW5JbnN0bklkPg0KCQkJCQk8cGFjczpCSUNGST5CQU5LQkVCQlpaWjwvcGFjczpCSUNGST4NCgkJCQk8L3BhY3M6RmluSW5zdG5JZD4NCgkJCTwvcGFjczpDZHRyQWd0Pg0KCQkJPHBhY3M6Q2R0cj4NCgkJCQk8cGFjczpObT5DUiBCQU5LPC9wYWNzOk5tPg0KCQkJPC9wYWNzOkNkdHI+DQoJCTwvcGFjczpDZHRUcmZUeEluZj4NCgk8L3BhY3M6RklUb0ZJQ3N0bXJDZHRUcmY+DQo8L3BhY3M6RG9jdW1lbnQ+ - identification: 20190417.UseCase3Message2 business_message_identifier: 'BBBB/200227-PSR/001' message_definition_identifier: pacs.008.001.08 business_service: swift.cbprplus.01 from: BANKBEAAYYY to: BANKBEBBZZZ message_direction: RECE message_content: >- PHBhY3M6RG9jdW1lbnQgeG1sbnM6cGFjcz0idXJuOmlzbzpzdGQ6aXNvOjIwMDIyOnRlY2g6eHNkOnBhY3MuMDA4LjAwMS4wOCI+DQoJPHBhY3M6RklUb0ZJQ3N0bXJDZHRUcmY+DQoJCTxwYWNzOkdycEhkcj4NCgkJCTxwYWNzOk1zZ0lkPkJCQkIvMjAwMjI3LVBTUi8wMDE8L3BhY3M6TXNnSWQ+DQoJCQk8cGFjczpDcmVEdFRtPjIwMjAtMDItMjdUMTc6NTA6MDArMDA6MDA8L3BhY3M6Q3JlRHRUbT4NCgkJCTxwYWNzOk5iT2ZUeHM+MTwvcGFjczpOYk9mVHhzPg0KCQkJPHBhY3M6U3R0bG1JbmY+DQoJCQkJPHBhY3M6U3R0bG1NdGQ+SU5EQTwvcGFjczpTdHRsbU10ZD4NCgkJCTwvcGFjczpTdHRsbUluZj4NCgkJPC9wYWNzOkdycEhkcj4NCgkJPHBhY3M6Q2R0VHJmVHhJbmY+DQoJCQk8cGFjczpQbXRJZD4NCgkJCQk8cGFjczpJbnN0cklkPk1NTU0vMjAwMjI3PC9wYWNzOkluc3RySWQ+DQoJCQkJPHBhY3M6RW5kVG9FbmRJZD5SRUZFUkVOQ0UwMDAyPC9wYWNzOkVuZFRvRW5kSWQ+DQoJCQkJPHBhY3M6VUVUUj5iNzYyZDNmMS02ZDkwLTQzNDctYTdmMi0yYjgxNDhiZjQ3ZjQ8L3BhY3M6VUVUUj4NCgkJCTwvcGFjczpQbXRJZD4NCgkJCTxwYWNzOkludHJCa1N0dGxtQW10IENjeT0iRVVSIj4xMDAuMDwvcGFjczpJbnRyQmtTdHRsbUFtdD4NCgkJCTxwYWNzOkludHJCa1N0dGxtRHQ+MjAyMC0wMi0yODwvcGFjczpJbnRyQmtTdHRsbUR0Pg0KCQkJPHBhY3M6SW5zdGRBbXQgQ2N5PSJFVVIiPjEwMC4wPC9wYWNzOkluc3RkQW10Pg0KCQkJPHBhY3M6Q2hyZ0JyPlNIQVI8L3BhY3M6Q2hyZ0JyPg0KCQkJPHBhY3M6RGJ0cj4NCgkJCQk8cGFjczpObT5EUiBCQU5LPC9wYWNzOk5tPg0KCQkJCTxwYWNzOlBzdGxBZHI+DQoJCQkJCTxwYWNzOkFkckxpbmU+TUFJTiBTVCwgMjAwMDwvcGFjczpBZHJMaW5lPg0KCQkJCQk8cGFjczpBZHJMaW5lPkFudHdlcnBlbiwgQkU8L3BhY3M6QWRyTGluZT4NCgkJCQk8L3BhY3M6UHN0bEFkcj4NCgkJCTwvcGFjczpEYnRyPg0KCQkJPHBhY3M6RGJ0ckFndD4NCgkJCQk8cGFjczpGaW5JbnN0bklkPg0KCQkJCQk8cGFjczpCSUNGST5CQU5LQkVBQVlZWTwvcGFjczpCSUNGST4NCgkJCQk8L3BhY3M6RmluSW5zdG5JZD4NCgkJCTwvcGFjczpEYnRyQWd0Pg0KCQkJPHBhY3M6Q2R0ckFndD4NCgkJCQk8cGFjczpGaW5JbnN0bklkPg0KCQkJCQk8cGFjczpCSUNGST5CQU5LQkVCQlpaWjwvcGFjczpCSUNGST4NCgkJCQk8L3BhY3M6RmluSW5zdG5JZD4NCgkJCTwvcGFjczpDZHRyQWd0Pg0KCQkJPHBhY3M6Q2R0cj4NCgkJCQk8cGFjczpObT5DUiBCQU5LPC9wYWNzOk5tPg0KCQkJPC9wYWNzOkNkdHI+DQoJCTwvcGFjczpDZHRUcmZUeEluZj4NCgk8L3BhY3M6RklUb0ZJQ3N0bXJDZHRUcmY+DQo8L3BhY3M6RG9jdW1lbnQ+ UseCase3-ScreeningRequest-Response: summary: Use case 3. Requests to screen the messages are accepted. Statuses are processing while the messages are being screened asynchronously. value: producer_identification: BOAPPL0001 status: - identification: 20190417.UseCase3Message1 last_update: '2021-04-17T14:35:11.000Z' status: PROC - identification: 20190417.UseCase3Message2 last_update: '2021-04-17T14:35:11.000Z' status: PROC UseCase4-ScreeningRequest: summary: Use case 4. Submit screening requests for one MT 800 and one MT 199 messages. MT 800 request refers to MT Standards 2019 where that message type was deprecated, to highlight that a batch of screening requests can be partially accepted. value: producer_identification: BOAPPL0001 screening_requests: - identification: 20190417.UseCase4Message1 business_message_identifier: 'TC0211251238' message_definition_identifier: fin.800.2019 message_content: >- ezE6RjAxQUxGUklOMzBBWFhYMDAwMDAwMDAwMH17MjpJODAwQUxGUklOMzBYWFhYVTF9ezM6ezEwODpNVDgwMCAwMDF9fXs0Og0KOjIwOlRDMDIxMTI1MTIzOA0KOjUxQzovMzA0OTUwDQo6MjM6MzQwLjY2OS44MTIzDQo6MzA6MDIxMTI1DQo6MjZBOjY5MTA0NDQ4LzQ0NTENCjoyNkE6Njk3MDEzMzEvMTMzNg0KOjI2QTo2OTI5Mjc0OC8yNzYwDQo6MzNCOkdCUDgxMCwNCjoyMzozNDAuNjY5LjgxMjQNCjozMDowMjExMjUNCjoyNkE6NzI0Njg1NDkvODU2Mg0KOjI2QTo3MjMxMTg4MC8xODk0DQo6MjZBOjY3MDQxMzIxLzEzMjINCjozM0I6R0JQNjQwLA0KOjM0QjpHQlAxNDUwLA0KOjE2QToyDQo6MzJBOjAyMTEyNkdCUDE0NTAsDQo6NTNBOkFCQ0RCRTIyDQo6NTRBOkRDQkFCRTMzDQotfQ== - identification: 20190417.UseCase4Message2 business_message_identifier: '20190417-123' message_definition_identifier: fin.199.2020 message_content: >- ezE6RjAxQUJDREJFMTFYWFhYOTk5OTk5OTk5OX17MjpJMTk5U1dIUUJFQkJYWFhYTn17Mzp7MTA4OjEyMzQ1Njc4OTN9fXs0Og0KOjIwOjIwMTkwNDE3LTEyMw0KOjc5OlRlc3QgbWVzc2FnZQ0KLX17Uzp7U0FDOn17Q09QOlB9fQ== UseCase4-ScreeningRequest-Response: summary: Use case 4. Request to screen message identified by UseCase4Message1 is rejected because the message definition identifier is invalid. The request for the other message is accepted. Status is processing while the latter message is being screened asynchronously. value: producer_identification: BOAPPL0001 status: - identification: 20190417.UseCase4Message1 last_update: '2021-04-17T14:35:11.000Z' status: ERRR error: code: TSS.MSG0003 severity: FATL text: Invalid message type user_message: Message type in the message definition identifier is unsupported by the Transaction Screening Service. - identification: 20190417.UseCase4Message2 last_update: '2021-04-17T14:35:11.000Z' status: PROC UseCase5-ScreeningRequest: summary: Use case 5. Submit screening request for one MT 199 message that does not comply with the MT standard (as field 00 does not exist). value: producer_identification: BOAPPL0001 screening_requests: - identification: 20190417.UseCase5Message1 business_message_identifier: 20190417-123 message_definition_identifier: fin.199.2020 message_content: >- ezE6RjAxQUJDREJFMTFYWFhYOTk5OTk5OTk5OX17MjpJMTk5U1dIUUJFQkJYWFhYTn17Mzp7MTA4OjEyMzQ1Njc4OTN9fXs0Og0KOjIwOjIwMTkwNDE3LTEyMw0KOjAwOlRlc3QgbWVzc2FnZQ0KLX17Uzp7U0FDOn17Q09QOlB9fQ== UseCase5-ScreeningRequest-Response: summary: Use case 5. Request to screen the message is accepted. Status is processing while the system attempts to parse the non compliant message. value: producer_identification: BOAPPL0001 status: - identification: 20190417.UseCase5Message1 last_update: '2021-04-17T14:35:11.000Z' status: PROC UseCase1-Status-a-Response: summary: Use case 1.a. Message was screened and an alert was created for review by a user. value: producer_identification: BOAPPL0001 sequence_number: '1234' status: - identification: 20190417.UseCase1Message1 last_update: '2019-04-17T14:35:11.000Z' status: PEND UseCase1-Status-b-Response: summary: Use case 1.b. Alert for message was reviewed and considered a false positive. value: producer_identification: BOAPPL0001 sequence_number: '8979' status: - identification: 20190417.UseCase1Message1 last_update: '2019-04-17T15:02:22.000Z' status: CMPL decision: decision: ALLO reason: USER UseCase1-Status-c-Response: summary: Use case 1.c. Alert for message was reviewed and considered a true positive. value: producer_identification: BOAPPL0001 sequence_number: '8979' status: - identification: 20190417.UseCase1Message1 last_update: '2019-04-17T15:02:22.000Z' status: CMPL decision: decision: BLOK reason: USER UseCase1-Status-d-Response: summary: Use case 1.d. Message was screened and a non-blocking alert was created (therefore not requiring a review by a user). value: producer_identification: BOAPPL0001 sequence_number: '1234' status: - identification: 20190417.UseCase1Message1 last_update: '2019-04-17T14:35:11.000Z' status: CMPL decision: decision: ALLO reason: NBLA UseCase1-Status-e-Response: summary: Use case 1.e. Message was screened and did not raise an alert. value: producer_identification: BOAPPL0001 sequence_number: '1234' status: - identification: 20190417.UseCase1Message1 last_update: '2019-04-17T14:35:11.000Z' status: CMPL decision: decision: ALLO reason: NOAL UseCase1-Status-f-Response: summary: Use case 1.f. Message was not screened. value: producer_identification: BOAPPL0001 sequence_number: '1234' status: - identification: 20190417.UseCase1Message1 last_update: '2019-04-17T14:35:11.000Z' status: CMPL decision: decision: ALLO reason: NOSC UseCase5-Status-Response: summary: Use case 5. Non compliance of the message is detected and causes the screening request to fail. value: producer_identification: BOAPPL0001 sequence_number: '1234' status: - identification: 20190417.UseCase5Message1 last_update: '2019-04-17T14:35:11.000Z' status: ERRR error: code: TSS.SRP0001 severity: FATL text: 'Screening has failed for this message with the following error: [Unexpected field 00:Test message at line 2, The content of field 4:\r\n:20:20190417-123\r\n:00:Test message has a wrong syntax at line 0, Unexpected end of message]' user_message: Screening request has failed security: - oauthBearerToken: []