Transaction Ingestion on Mesh - Payment Screening

Last updated: May 18, 2026

Transactions for Payment Screening can be submitted in two ways:

  • Via a synchronous API end point

  • Via batch (UI & API end point)

Each transaction has to have a related customer record in Mesh.
Our system will check for an existing record and create any required customers automatically in Mesh where needed.

For a full technical understanding of our transaction attributes and capabilities please review our Transaction API documentation.


Single transaction ingestion

Through synchronised transaction ingestion, you can submit payments in real-time via a synchronous API endpoint, ensuring you perform immediate transaction screening. This ingestion path serves as your critical frontline defence, enabling you to verify transaction details—including i.e. the sender, receiver, and intermediary banks—against global sanctions and custom-managed lists with sub-second latency. By embedding this synchronous flow directly into your transaction authorisation chain, you can block or flag high-risk payments instantly, allowing you to prevent financial crime before a transaction is processed.

Mesh cross-product information

If you want to run Payment Screening and Transaction Monitoring together on the sync flow then the latency/speed we can achieve overall is bound to the slowest component (TM) and we will not hit the 250ms latency target for PS. If you want to achieve sub-second latency on PS you need to choose the following transaction ingestion path combination:


a) PS synchronous ingestion flow
b) TM asynchronous ingestion flow

It is specified in  the body parameters of the API documentation


Batch transaction upload

With batch transaction upload, you can submit large volumes of payments to be evaluated by Payment Screening in Mesh via either the user interface or an API endpoint. 

This ingestion method is ideal for non-urgent payments, as it allows you to consolidate a wide variety of transactions and related fields before submitting them to our system. 

When preparing your files, you have the flexibility to either link transactions to your existing customer records or perform inline customer creation and updates directly from the batch. 

While the process acts as an asynchronous entry point to manage high throughput, it ensures your data is securely stored and readily accessible for remediation, helping you maintain robust compliance without the sub-second latency constraints of real-time screening.

Any data you send is stored securely in Mesh and returned via API and in the web app.

Managing customers

Transactions need to be attached to a customer record. For the fastest evaluation of transactions, users should attach the transaction to a pre-existing customer. However, we also offer the ability to update or create a customer in Mesh at the time of transaction processing.

Full details of your options are on our API docs.

Restriction

Each file uploaded to the batch uploader must contain only one of the following methods:

  1. The customer external ID is provided at the top level and the customer object is not provided. i.e. all transactions use existing customers with no in-line customer creation or update.

  2. The customer external ID is provided at the top level and the customer object is also provided. i.e. all transactions include customer details in the customer object to update existing customers or create new customers.