Salv monitoring-checks API

Person & Transaction monitoring. Real-time (ONLINE) scenarios should be used when an alert created by the scenario should block the transaction. [Example: Real-time (pre-processing) transaction monitoring](#tag/monitoring-overview/Example:-Real-time-(pre-processing)-transaction-monitoring) Post-event (OFFLINE) scenarios should be used when an alert created should NOT block the transaction. [Example: Simple integration](#tag/aml/Example:-Uploading-person-and-transaction) In the rare occasion that a monitoring check fails with error code 500, the transaction should be blocked. In that case Salv has not been able to verify that the transaction is safe to process.

OpenAPI Specification

salv-monitoring-checks-api-openapi.yml Raw ↑
openapi: 3.0.3
info:
  title: Salv AML alert monitoring-checks API
  description: '# Introduction

    Welcome to the Salv AML API documentation.


    The Salv API is built on HTTP. Our API is RESTful. It has predictable resource URLs. It returns HTTP response codes to indicate errors. It also accepts and returns JSON in the HTTP body. You can use your favorite HTTP/REST library for your programming language to use Salv API.


    API definition to import into Postman can be downloaded at https://docs.salv.com/api/public.yaml

    '
  version: 1.0.9
  contact:
    name: Support
    email: support@salv.com
  x-logo:
    url: salv.svg
    altText: Salv API
servers:
- url: https://{environment}.salv.com/api/
  variables:
    environment:
      default: app
      enum:
      - app
      - demo
      description: 'Select environment:

        * `app` - Production

        * `demo` - Sandbox

        '
security:
- OAuth2:
  - aml
tags:
- name: monitoring-checks
  description: 'Person & Transaction monitoring.


    Real-time (ONLINE) scenarios should be used when an alert created by the scenario should block the transaction. [Example: Real-time (pre-processing) transaction monitoring](#tag/monitoring-overview/Example:-Real-time-(pre-processing)-transaction-monitoring)


    Post-event (OFFLINE) scenarios should be used when an alert created should NOT block the transaction. [Example: Simple integration](#tag/aml/Example:-Uploading-person-and-transaction)


    In the rare occasion that a monitoring check fails with error code 500, the transaction should be blocked. In that case Salv has not been able to verify that the transaction is safe to process.

    '
  x-displayName: Monitoring checks
paths:
  /v1/persons/{personId}/monitoring-checks:
    post:
      tags:
      - monitoring-checks
      summary: Run real-time (ONLINE) person monitoring checks
      operationId: runPersonMonitoringChecks
      parameters:
      - name: personId
        in: path
        description: ID of a person
        required: true
        schema:
          type: string
          minLength: 1
      - name: all-results
        in: query
        description: Return all results regardless of scenario score
        required: false
        schema:
          type: boolean
      responses:
        '200':
          description: successful operation
          content:
            application/json:
              schema:
                $ref: models.yaml#/components/schemas/ApiScore
        '400':
          description: Invalid ID supplied
        '404':
          description: Person not found
        '500':
          description: Execution of monitoring checks failed
          content:
            application/json:
              schema:
                $ref: models.yaml#/components/schemas/ApiExceptionMonitoringChecksFailed
  /v1/transactions/{transactionId}/monitoring-checks:
    post:
      tags:
      - monitoring-checks
      summary: Run real-time (ONLINE) transaction monitoring checks
      operationId: runTransactionMonitoringChecks
      parameters:
      - name: transactionId
        in: path
        description: ID of transaction
        required: true
        schema:
          type: string
          minLength: 1
      responses:
        '200':
          description: successful operation
          content:
            application/json:
              schema:
                $ref: models.yaml#/components/schemas/ApiScore
        '400':
          description: Invalid ID supplied
        '404':
          description: Transaction not found
        '500':
          description: Execution of monitoring checks failed
          content:
            application/json:
              schema:
                $ref: models.yaml#/components/schemas/ApiExceptionMonitoringChecksFailed
components:
  securitySchemes:
    OAuth2:
      type: oauth2
      description: 'In order to use the API, you need to generate client credentials using [Salv UI](https://demo.salv.com/credentials).

        Never share your secret keys. Keep them guarded and secure.


        We use OAuth2 client credentials flow to issue our API tokens.

        By default our API tokens have expiration time of 50 years, so effectively they never expire.

        Please do not make any assumptions about the content of the access_token.

        At the moment we use a JWT token, but it can change to any other string with the future updates.


        An API token can be invalidated using Salv UI by deleting the client credentials that were used to generate the token.


        Please make sure you only request it once per reasonable amount of time,

        as `oauth/token` endpoint has a rate limit of **10 requests per minute** per IP address.


        | Environment | Token URL |

        |-------------|-----------|

        | Production | `https://app.salv.com/oauth/token` |

        | Sandbox | `https://demo.salv.com/oauth/token` |


        Use the token URL matching your selected server environment.

        '
      flows:
        clientCredentials:
          tokenUrl: https://app.salv.com/oauth/token
          x-tokenUrl-sandbox: https://demo.salv.com/oauth/token
          scopes:
            aml: Can use AML API
x-tagGroups:
- name: General
  tags:
  - changelog
  - getting-started
  - data-upload
  - aml
  - note
  - webhooks
  - custom-list-record
  - custom-list-usable-field-public
- name: Monitoring
  tags:
  - monitoring-overview
  - monitoring-checks
  - alert
- name: Screening
  tags:
  - screening-overview
  - screening-checks
  - screening-searches
  - screening-list-groups
  - screening-alerts
- name: Risks
  tags:
  - risk
- name: Alert management
  tags:
  - alerts
  - manual-alerts
- name: Deprecated
  tags:
  - unresolved-alerts