module A giving more information to module B which it doesn't need to do it's job
Word "need" may be confusing unless one clearly specifies the needs. It is true that module B doesn't need this information to get the processing result, but it is also true that without this information, its results are useless for module C. In that sense, additional information serves a different kind of need - an integration need.
POSA 2 book presents a pattern intended to serve similar need - Asynchronous Completion Token:
This design pattern allows an application to demultiplex and process efficiently the responses of asynchronous operations it invokes on services. (quoted from POSA 2 patterns abstracts page)
Book presents a real life example to help understand the pattern: FedEx inventory tracking
...An intriguing real-life example of the Asynchronous Completion Token pattern is implemented by the inventory tracking mechanism used by the US Federal Express postal services. A FedEx Airbill contains a section labeled: 'Your Internal Billing Reference Information (Optional: First 24 characters will appear on invoice).' The sender of a package uses this field as an ACT. This ACT is returned by FedEx (the service) to you (the initiator) with the invoice that notifies the sender that the transaction has completed. FedEx deliberately defines this field very loosely: it is a maximum of 24 characters, which are otherwise 'untyped.' Therefore, senders can use the field in a variety of ways. For example, a sender can populate this field with the index of a record for an internal database or with a name of a file containing a 'to-do list' to be performed after the acknowledgment of the FedEx package delivery has been received.
You see, above example is quite close to what you describe. Guys "in the middle of FedEx chain" may say they don't really need billing reference, all they need to know is delivery address. But sender may use it when they need to be notified about transaction completion. That's an integration kind need.
For the sake of completeness note, there's an approach avoiding need to pass the "identification" info to module B. Module B could return its results to module A from synchronous blocking call. Upon return, module A could "enrich" obtained results with whatever additional info and pass it further to module C.
This way is not necessarily better than yours - for example, it loads module A with additional burden of knowing about module C, which isn't the case in your approach. That's why above answer doesn't dive into what approach to choose and when and instead, simply assumes that passing control from A to B then to C has been preferred for whatever reasons.