The problem I have it´s that the xml is not well formed, ...
The term well-formedness is technical with very rich meaning. If your interceptor or otherwise the shown code can perform to such an extent of giving you back strBody etc, for instance, the soapmsg received is most probably well-formed. But I think we understand what you meant: it simply means it does not work with your code to begin with!
I am doubtful cxf will eventually complain of a missing namespace declaration xmlns:xsd="...", because those xsd:string or alike is not directly exposed in the payload of the
soap message. Hence, an xmlns:xsd is strictly speaking not necessary and I think the provider refuses with probably good reason to change anything in that regard. The trouble probably comes from the client-side mapping (unmarshalling) to annotated pojo... You might like to take a look of @XmlSchema annotation sometimes appears in the package-info... just a suggestion.
If we take a blind eye on all that root causes of the trouble and only pursue on a local objective of adding an xmlns:xsd declaration via an interceptor, we can do that. You can before return strBody do a series of string operation on strBody by regex or common string functions by adding xmlns:xsd="http://www.w3.org/2001/XMLSchema" to the root element, after verifying that it is not there... This sure can be done and
you should be able to do it look it that way.
But that is hardly a homogeneous use of xml technology. The cardinal way is certainly inserting a specifically designed xslt and transform the payload as Document object itself before serializing it to strBody. This can be done the way I outline below. We can do many things with the xslt 1.0 ordinarily most broadly used version. _But_, what is intriguing is that to add such a "purposeless" (in the sense that it serves nothing at all for validating and/or parsing with schema-aware parser) namespace delaration, in particular, is difficult even impossible (or severly discouraged by coding) in xslt 1.0. In xslt 2.0, this thing sees the light and can now be done with xslt 2 with its specific element xsl:namespace.
You can construct an xslt document (notice: version="2.0") like this.
Apply this xslt to the transformer instead of applying nothing (which means an identity transformation is used by default), see below. But this xslt is distinctly xslt 2.0, you also have to apply an xslt2.0 processor to the interceptor. The most convenient is to load up Saxon 9. The free version is pretty enough. Adding all necessary classpath(s) etc... Then the modification on the interceptor is limited to a couple of lines.
With all the above, you should be done.