Mediator not detecting faults when WS-Security Message Encryption enabled

Question

We are using a SOA 11g composite to call a set of OSB proxy/business pairs which in turn call further web services and return the responses. The OSB proxy services are trivial: they each expose the WSDL of the downstream web service and route all messages without any transformation to a business service that also uses the downstream WSDL.
The SOA composite is composed largely of a mediator that accepts requests, transforms payloads, routes to the correct OSB service, transforms the response, and replies to the caller.
I have configured my OSB services, in case of a SOAP fault returned from downstream, to simply "Reply with Failure", which causes the body received from the downstream web service (a SOAP fault) to be returned to the SOA composite along with an HTTP 500 error. I have created a Fault processing section in each of my routing rules that maps the downstream fault to a fault that the mediator returns to the caller.
In my local test instance, this works fine; OSB receives a custom SOAP fault from the downstream service, sends it back to SOA where the mediator recognizes the fault and maps it, and throws a SOAP Fault back to the caller.
In our formal testing environment, however, it does not work. I have validated that the response comes back to the Mediator in the same way as it does in my local environment, but the Mediator attempts to use the standard response transformation configured for that routing rule rather than the fault transformation. The fundamental difference between my local environment and the formal test environment is that WS-Security has been enabled between SOA and OSB using the wss10_username_token_with_message_protection via OWSM.
I have a workaround, namely to add a choose clause in my reply transformation XSL file that looks for a SOAP fault and sends it back to the caller if one is found, however this is a nasty hack.
Has anyone had experience with this scenario, where implementing WS-Security causes SOAP Faults to no longer be recognized? My best guess at this point is that when "Reply with Failure" is used, OSB returns the SOAP Fault body in an encrypted form and SOA assumes that the call succeeded (despite the HTTP 500 error). I have not found a way to tell OSB not to encrypt the response message in the case of "Reply with Failur", but it doesn't encrypt responses when it throws its own faults (BEA-380001, for instance).

Answer 1

X509V1 is not a valid value for "Valuetype". So I guess this should not be the problem.