# QI Tech — Risk Solutions › Account Monitoring Documentação da QI Tech em texto corrido, para colar em um LLM. Fonte: https://docs.qitech.com.br 7 página(s). Índice: - Account Creation (/en/documentation/caas/account_monitoring/account_registration) - authentication (/en/documentation/caas/account_monitoring/authentication) - HTTP Status (/en/documentation/caas/account_monitoring/http_status) - Introduction (/en/documentation/caas/account_monitoring/introduction) - Person Creation (/en/documentation/caas/account_monitoring/person_registration) - Standards (/en/documentation/caas/account_monitoring/standards) - Webhook (/en/documentation/caas/account_monitoring/webhook) --- # Account Creation URL: /en/documentation/caas/account_monitoring/account_registration The Account Monitoring Product is divided into Individual Accounts (Natural Person) and Corporate Accounts (Legal Person). An Individual Account may contain only natural persons, while a Corporate Account may contain both legal entities and natural persons. To create an account, simply send an object of type _Account_ to one of the following endpoints: - Individual Account (Natural Person) `POST https://api.caas.qitech.app/account_monitoring/natural_person_account` > Example ```json { "account_id": "5ce7fab5-8165-44a5-9b89-bb2d6d61e4f4", "registration_date": "2019-12-20T15:23:12" } ``` - Corporate Account (Legal Person) `POST https://api.caas.qitech.app/account_monitoring/legal_person_account` > Example ```json { "account_id": "5ce7fab5-8165-44a5-9b89-bb2d6d61e4f4", "registration_date": "2019-12-20T15:23:12" } ``` All information exchanges related to an account registration use the following object definition. In some cases, to simplify the implementation and reduce data flow between parties, some information may be omitted. name | type | description :----: | :----: | --------- account_id | string | Unique account identifier. **This value must be unique for each request** registration_date | string (ISO 8601) | Account registration date and time. ## Account Deactivation and Reactivation To deactivate an account within the Account Monitoring product, send a request to the following endpoint with the payload below, setting the `new_account_status` field to `deactivated`: - Individual Account (Natural Person) `PATCH https://api.caas.qitech.app/account_monitoring/natural_person_account/{account_id}` > Example ```json { "new_account_status": "deactivated" } ``` - Corporate Account (Legal Person) `PATCH https://api.caas.qitech.app/account_monitoring/legal_person_account/{account_id}` > Example ```json { "new_account_status": "deactivated" } ``` This will deactivate the account and interrupt its monitoring. To reactivate an account — and consequently resume its monitoring — send a request to the same endpoint, now setting `new_account_status` to `active`: - Individual Account (Natural Person) `PATCH https://api.caas.qitech.app/account_monitoring/natural_person_account/{account_id}` > Example ```json { "new_account_status": "active" } ``` - Corporate Account (Legal Person) `PATCH https://api.caas.qitech.app/account_monitoring/legal_person_account/{account_id}` > Example ```json { "new_account_status": "active" } ``` When an account is reactivated, the monitoring intervals for all account topics are reset. For example, if all topics are monitored every 24 hours, after reactivation the updates will occur 24 hours after the account is reactivated. --- # authentication URL: /en/documentation/caas/account_monitoring/authentication ## Authentication > To authenticate a request, use the following code: ```shell # In the shell, you only need to add the appropriate header to each request curl "api_endpoint_here" -H "Authorization: EXAMPLE_API_KEY" ``` > Replace the API key `EXAMPLE_API_KEY` with the key provided by our support team. We use an API Key to allow access to our API. It was most likely already sent to you by email. If you have not yet received your key, please send an email to suporte.caas@qitech.com.br . Our API expects the API Key to be sent in all requests to our server using a header like the one below: `Authorization: EXAMPLE_API_KEY` :::info **Attention** You must replace EXAMPLE_API_KEY with the API Key provided by the support team. ::: --- # HTTP Status URL: /en/documentation/caas/account_monitoring/http_status All QI Tech APIs use the following standardization for HTTP response status codes, in accordance with RFC 7231 : HTTP Status | Meaning | Description ---------- | ------- | --------------------------------- 400 | Bad Request | The request sent contains a formatting error. In most cases, we return an explanation in the response body indicating where the error is. 401 | Unauthorized | There was an authentication issue. Please verify that the API Key is correct and sent in the proper header, according to the Authentication section. 403 | Forbidden | The accessed endpoint is for internal use and is not available for this API Key. 404 | Not Found | The requested data was not found using the provided key. This status is also returned when an invalid endpoint is requested. 405 | Method Not Allowed | The HTTP method used does not apply to the accessed endpoint. 406 | Not Acceptable | The data sent in the request body is invalid. In general, this means the payload is not a valid JSON. 409 | Conflict | The request ID corresponds to an ID that has already been processed. This status is returned in the case of duplicate requests sent to the server. 500 | Internal Server Error | We encountered an issue while processing this request. When this error occurs, our specialists are automatically notified and immediately begin analysis and resolution. 503 | Service Unavailable | You have encountered a planned or unplanned infrastructure outage of our servers. --- # Introduction URL: /en/documentation/caas/account_monitoring/introduction Welcome to the QI Tech Account Monitoring API! You can use our API to monitor accounts and individuals across several monitoring topics, respecting fully customizable monitoring intervals according to the client’s demands and needs. Today, the product supports the following monitoring topics: - For Individuals (Natural Persons); - OFAC List – Sanctions List from the Office of Foreign Assets Control - UNSC List – Sanctions List from the United Nations Security Council - IBAMA List – Environmental Penalties List from the Brazilian Institute of Environment and Renewable Natural Resources - PEP List – Politically Exposed Persons List - Federal Revenue Status – Registration status with the Brazilian Federal Revenue Service - For Legal Entities (Companies); - OFAC List – Sanctions List from the Office of Foreign Assets Control - UNSC List – Sanctions List from the United Nations Security Council - IBAMA List – Environmental Penalties List from the Brazilian Institute of Environment and Renewable Natural Resources - CEIS List – Registry of Ineligible and Suspended Companies - CNEP List – National Registry of Punished Companies - Federal Revenue Status – Registration status with the Brazilian Federal Revenue Service Please note that monitoring intervals are defined per monitoring topic and per type of monitored entity. For example, the OFAC List can be monitored every 10 days for Individuals and every 30 days for Legal Entities. The monitoring interval for each topic follows the ISO 8601 standard and can be any of the intervals listed below, or a combination of them: ### Days, Weeks, Months, and Years | Notation | Meaning | |----------|---------| | `"P1D"` | 1 day | | `"P7D"` | 7 days | | `"P1W"` | 1 week | | `"P1M"` | 1 month | | `"P1Y"` | 1 year | --- ### Hours, Minutes, and Seconds | Notation | Meaning | |-----------------|----------------------------------| | `"PT1H"` | 1 hour | | `"PT30M"` | 30 minutes | | `"PT45S"` | 45 seconds | | `"PT2H30M"` | 2 hours and 30 minutes | | `"PT1H15M10S"` | 1 hour, 15 minutes, and 10 seconds | --- ### Custom Examples | Notation | Meaning | |---------------------|---------------------------------------------| | `"P1DT12H"` | 1 day and 12 hours | | `"P2W3DT4H30M"` | 2 weeks, 3 days, 4 hours, and 30 minutes | Below, you can see an example implementation of the API using curl. These examples can be adapted to the programming language of your choice. ## Problems? We are not a company that hides behind an API! Contact our support team and we will respond as quickly as possible. Feel free to call us if you need a faster response! ### We Love Feedback Even if you have already solved your issue or if it is very simple (even a typo or a formatting issue that you already understood), send us an email. This helps us make the documentation more practical so the next person doesn’t have to go through the same pain you did! ## Environments We provide two environments for our clients. The base URLs for the APIs are: * Production – `https://api.caas.qitech.app/account_monitoring/` * Sandbox – `https://api.sandbox.caas.qitech.app/account_monitoring/` In the Sandbox environment, submitted analyses are not charged and are answered according to predefined rules. ## HTTPS Only For security reasons, all communication with QI Tech APIs must be performed using HTTPS. To prevent HTTP calls due to inattention or other reasons, this server only exposes port 443 with TLS 1.2 communication. Requests made using other protocols will be automatically denied. ## Authentication > To authenticate a request, use the following code: ```shell curl "api_endpoint_here" \ -H "Authorization: EXAMPLE_API_KEY" --- # Person Creation URL: /en/documentation/caas/account_monitoring/person_registration To create people for their respective accounts, segregation between the natural_person_account and legal_person_account endpoints must be maintained. To request the creation of a person for an account, simply send a Person object to one of the following endpoints, respecting the segregation defined during account creation. ## Individual Account (Natural Person) ### Natural Person Creation `POST https://api.caas.qitech.app/account_monitoring/natural_person_account/{account_id}/natural_person` > Example ```json { "id": "cc2f97ba-08c8-4a91-8d0d-49313a6c1245", "registration_date": "2024-11-04T13:37:00Z", "data": { "name": "John Doe", "document_number": "123.456.789-09", "birthdate": "2000-07-13" } } ``` ### Legal Person Account - Natural Person Creation `POST https://api.caas.qitech.app/account_monitoring/legal_person_account/{account_id}/natural_person` > Example ```json { "id": "cc2f97ba-08c8-4a91-8d0d-49313a6c1245", "registration_date": "2024-11-04T13:37:00Z", "data": { "name": "John Doe", "document_number": "123.456.789-09", "birthdate": "2000-07-13" } } ``` The birthdate field is mandatory only for accounts that have status monitoring with the Brazilian Federal Revenue Service. It is required to query individuals under 18 years old. - Legal Person Creation `POST https://api.caas.qitech.app/account_monitoring/legal_person_account/{account_id}/legal_person` > Example ```json { "id": "cc2f97ba-08c8-4a91-8d0d-49313a6c1245", "registration_date": "2024-11-04T13:37:00Z", "data": { "name": "Empresa das Tampas", "document_number": "12.482.243/0001-34" } } ``` ## Person Deactivation and Reactivation The deactivation and reactivation of people follows the same logic used for accounts, using the endpoints below. ### Natural Person Account - Natural Person `PATCH https://api.caas.qitech.app/account_monitoring/natural_person_account/{account_id}/natural_person` > Example ```json { "new_person_status" : "deactivated" } ``` ### Legal Person Account - Natural Person `PATCH https://api.caas.qitech.app/account_monitoring/legal_person_account/{account_id}/natural_person` > Example ```json { "new_person_status" : "deactivated" } ``` - Legal Person `PATCH https://api.caas.qitech.app/account_monitoring/legal_person_account/{account_id}/legal_person` > Example ```json { "new_person_status" : "deactivated" } ``` To reactivate previously deactivated people, the operation is the same as the one used to deactivate people, but sending new_person_status as active to the following endpoints: ### Natural Person Account - Natural Person `PATCH https://api.caas.qitech.app/account_monitoring/natural_person_account/{account_id}/natural_person` > Example ```json { "new_person_status" : "active" } ``` ### Legal Person Account - Natural Person `PATCH https://api.caas.qitech.app/account_monitoring/legal_person_account/{account_id}/natural_person` > Example ```json { "new_person_status" : "active" } ``` - Legal Person `PATCH https://api.caas.qitech.app/account_monitoring/legal_person_account/{account_id}/legal_person` > Example ```json { "new_person_status" : "active" } ``` --- # Standards URL: /en/documentation/caas/account_monitoring/standards To facilitate integration and ensure data integrity, some standards have been defined and are followed throughout the entire API. ## Date and Time with Time Zone > Some examples: ``` 2019-10-15T22:35:12-03:00 2018-05-01T13:32:11+00:00 2019-05-01T00:00:00+00:00 ``` It is represented according to ISO 8601. In this case, the time zone is placed right after the time and must represent the time zone of the location where that data is valid. For example, if a rental is scheduled to start at 09:30 at Brasília airport, the time sent must be represented as 09:30-03:00. If the rental is scheduled to start at 09:30 in Manaus, it must be represented as 09:30-04:00. The validation mask used is the following: `YYYY-MM-ddThh:mm:ss±hh:mm` ## Date and Time without Time Zone > Some examples: ``` 2019-10-15T22:35:12Z 2018-05-01T13:32:11Z 2019-05-01T00:00:00Z ``` It is represented according to ISO 8601. Data that does not depend on a time zone must be sent without it, always in UTC, with the letter `Z` indicating that the data is in UTC. Therefore, the following format will be validated: `YYYY-MM-ddThh:mm:ssZ` ## Date > Some examples: ``` 2019-10-15 2019-01-01 2017-03-20 ``` For fields that accept only a date, such as a birthdate, only the date should be sent, without any time, using the following format: `YYYY-MM-dd` ## Documents Since document numbers can vary greatly and many of them contain non-numeric characters, all document numbers are defined as strings. Another important reason to define them as strings is to prevent leading zeros from being lost. Documents listed on this page have a well-defined mask and will be subject to validation. Other documents, such as RG, due to their lack of standardization, will not be validated. ## CPF > Examples of CPFs valid against the defined mask: ``` 123.456.789-12 321.987.543-23 111.283.333-00 ``` > Examples of CPFs invalid against the defined mask: ``` 8.577.477-8 08.104.627/0001-23 123.456.789-1 23.456.789-01 ``` The CPF is always defined as a string and will be validated against the mask: `###.###.###-##` ## CNPJ > Examples of CNPJs valid against the defined mask: ``` 08.104.627/0001-02 01.079.210/0114-67 32.402.502/0001-35 ``` > Examples of CNPJs invalid against the defined mask: ``` 8.577.477-8 123.456.789-12 321.987.543-23 32.402.502/0001-3 032.402.502/0001-3 ``` The CNPJ is always defined as a string and will be validated against the mask: `##.###.###/####-##` --- # Webhook URL: /en/documentation/caas/account_monitoring/webhook Webhook Updates to monitoring topics will be notified through webhook deliveries. To enable this, it is necessary to configure—through the [support](mailto:suporte.caas@qitech.com.br) team—an endpoint address where we will send update notifications, as well as a *signature_key* that will be used to sign the request. It is important to note that all webhook deliveries will be sent to a single endpoint. :::info **Attention** For security reasons, all Webhook requests will only be made to endpoints served over HTTPS. ::: ## Webhook Signature ## Event Update Webhook Request Body ```json { "person_type" : "natural_person", "account_type" : "natural_person_account", "person_id" : "22f5d028-0ce7-46f7-9b63-e7e38171b485", "account_id" : "e49ac344-f941-4668-9afb-a52ce4e5754a", "monitoring_topic" : "OFAC", "event" : "entered" } ``` Below is the meaning of each field: | Name | Type | Description | |:-----------------:|:------:|-----------------------------------------------------------------------------| | person_type | string | Person type (`natural_person` or `legal_person`). | | account_type | string | Account type (`natural_person_account` or `legal_person_account`). | | person_id | string | Unique identifier of the person, provided in the creation request. | | account_id | string | Unique identifier of the account, provided in the creation request. | | monitoring_topic | string | Monitoring topic in which the change occurred. | | event | string | Type of event that occurred, such as `"entered"` or `"exited"` for restrictive list topics. | The monitoring topic update request follows the format above and notifies a change in the status of one of the monitoring topics within the account. The HTTP method used is PUT, and the endpoint URL may also contain the event ID, depending on the client's needs. It is important to note that the request body is sent as UTF-8 encoded text. ## Retries The notification is considered successfully delivered when an HTTP 200 status is returned. If delivery fails, up to 7 retry attempts will be made with the following intervals, until a 200 response is received or all attempts are exhausted: * 10 seconds * 40 seconds * 160 seconds * 640 seconds * 2560 seconds * 10240 seconds * 40960 seconds