I have been thinking a bit about this question and I think I found a way to get composed IDs, meaningful enough for us to search and correlate *files, accounts and transactions*.

 account_id@sercive_name://file_path/file_name.ext

It's basically a URI. Meaningful enough for us to know *the account*, *the file where It came from* and *the service involved in its processing*.

Now, we would have to decide where to put the correlation ID that identifies the whole transaction. 

It could be at the query string

 account_id@sercive_name://file_path/file_name.ext?transaction=ID

Or it could be part of the credentials <sup>*</sup>

 account_id:tx_id@sercive_name://file_path/file_name.ext


Services only need to replace *service_name* by its own name (or any kind of service code we might have).

We could add even more information, as for instance the date of the process

 account_id@sercive_name://file_path/file_name.ext?transaction=ID&intake=yyyy-MM-ddTHH:mm:ss+00:00

In distributed systems, could be interesting to know the instance of the service too. For example, as a subdomain

 account_id@sercive_name.instance.server_name://file_path/file_name.ext?transaction=ID&intake=yyyy-MM-ddTHH:mm:ss+00:00


No need to say that we could swap the position of the elements. For example

 tx_id@sercive_name.instance.server_name://file_path/file_name.ext?account=account_id&intake=yyyy-MM-ddTHH:mm:ss+00:00

Or

 tx_id@sercive_name.instance.server_name://accounts/{id}?file=file_name.ext&intake=yyyy-MM-ddTHH:mm:ss+00:00

Just find out which one suits your needs of querying. Just remember that the more info It has, the less chance for collision and more information is retrieved per query.

---
<sup> * Honestly, the last one doesn't like me as much as the first. If I had to choose, I would go for the first.</sup>