Last first: I have no experience with MQFTE.
I am not convinced that service virtualization should be attempted for this scenario since you added requirements to evaluate data in the list for certain conditions. Virtual Services should be able to provide responses to a specific, well-known, well-defined set of input request criterion and provide a method (META) to send a generic response for all other scenarios that do not match the specific requirements. It does not feel like this is where the requirement is heading.
I would seek to limit as much as possible the number of valid values that you compare on in order to make a determination of what business scenario the data is responding to.
Any scenario that supports a unknown number of completely dynamic input data tags is a recipe for failure because the service has to cater for an what amounts to an unlimited number of scenarios and permutations.
I assume that the next requirement will be that the recurring XML data sent by the consumer has no positional order from one service call to the next. Let's consider an example:
Assume that you have 3 occurrences of <books><book>1</book><book>2</book><book>3</book>.
And, the consumer can send these books in any sequence. This means you have to cater for a minimum of 6 different order scenarios assuming the book IDs remain as 1, 2, 3.
Call 1: <books><book>1</book><book>2</book><book>3</book>
Call 2: <books><book>1</book><book>3</book><book>2</book>
Call 3: <books><book>2</book><book>1</book><book>3</book>
Call 4: <books><book>2</book><book>3</book><book>1</book>
Call 5: <books><book>3</book><book>2</book><book>1</book>
Call 6: <books><book>3</book><book>1</book><book>2</book>
Extend the requirement to a possible range of 1 - 50 books (50 scenarios) where the books can occur in any positional order and the matching logic within the service becomes too unruly to manage.
Add to this requirement the notion of values that might cross reference across the range (i.e.,
if book ID 1 exists in the list and book ID 4 exists in the list, then send this response,
if book ID 1 exists in the list and book ID 4 exists in the list AND book ID 12 is NOT in the list, send this response
Supporting these types of scenarios will require too much time to develop for the value it delivers.
If the business partner can isolate some specific data scenarios, there is likely an implementation that will work. Presently, it seems that the business partner is unable to communicate this information.
In these situations, I try to find a value or couple of values in the request that identify the business response behavior. For example, if the email address ends with "@test1.com" send answer for 1, "@test2.com" send answer for 2, and so on. It is not clear that you are able to do this.