Transaction Enrichment Ingress & Egress
This section documents the expected message input format and output formats. They are consistent across all interfaces provided, API, Kafka and SFTP.
The predominant choice you need to make when getting the transactions is whether you would like the data denormalised or normalised.
- Denormalised: More data initially, but means you don’t have to join the original transactions with the enriched fields.
- Normalised: Basic transaction data. You will need to match this up with later calls to enriched data.
If the denormalised format is chosen in the API and Kafka cases, the original transaction is returned, with full enrichment details contained in a nested object. mh_insights
Normalised format only contains the identifiers, e.g. transaction_id, from the original transaction with identifiers for the enriched details. Further data can then be obtained via our REST API using these identifiers.
With SFTP, the denormalised format has a single row per transaction containing all enrichment details. The normalised format will have a row per transaction with counterparty and geotag IDs. Separate counterparty and geotag files contain the full details of each counterparty/geotag to create the full enrichment record. Normalised format produces a much smaller data transfer.
JSON is the standard format in use for the API and Kafka interfaces. For SFTP, we support CSV by default with each transaction on a new line. As data drops can be larg,e we do support alternatives such as Avro or Parquet.
Updated about 2 months ago