java design - objects to be logically handled in similar way but might not have common members/ methods etc

I am writing a suite of java classes that will be doing network requests on the basis from the information produced from our application. Most likely there will be several of these kind of suites in the future -- sending out certain data to other platforms/clients/partners etc. The input for those suites will be the same set of data (will be provided at the integration point from our app and i have no control over it) But this input will be converted to different data objects before creating the requests from these data objects.

Example pseudocode line

List(InputObjects) --> transformator --> List(RequestDTOs) --> requestcreator(creates and sends buch of requests based on DTOS).

I would like to encourage the future coders to use the same format for all the other suites. For ease of understanding and maintenance in the future.

So I would like to define interfaces/abstract classes etc. for "transformator" and "requestcreator". It would be easy to declare abstract superclass for RequestDTO and then let different suites extend it. But the thing is the RequestDTOs actually might have completely different fields with nothing shared. So one would make and abstract superclass with no members in this case. I do not like this idea much.

Would this be a good idea to mark RequestDTOs with annotation or marker (empty) interface?

Or could I just write the transformation as providing unspecified Collection as return type let the creator take in similar as input?

I would not like this latter idea I think -- I should the use Object as collection element type as trying to make generics for the elements would lead back to the problem that they might have not much in common except a certain "meta" logical position in the process flow that I would like the future users of the code to immediately recognize)

Any other ideas?