This colour usually comes from the texture itself. When using alpha transparency, even fully transparent texels still have an RGB colour, though it's usually unseen. Because we don't see it, image editors and compression tools can be inconsistent in how they handle these areas - filling them with white, black, or streaked-out copies of adjacent texels to improve predictability for compression.
The most reliable way I've found to control this is to use TGA (Targa) files for intermediate texture storage (before converting to GPU compressed formats like DXT-5 etc. when generating an executable build). Targa files don't assume that the alpha channel is transparency, so you can export arbitrary RGBA data without a compressor second-guessing what the 0-alpha texels should look like.
If you're using Photoshop or a similar tool, you'll want to create an alpha mask from the transparency of your texture, and store it as a new alpha channel. Then go back to the RGB colour planes, and paint a border behind any transparent edges of your texture, matching the colours of adjacent texels. This way you can ensure any blending with these texels during mipmapping or texture filtering won't distort the RGB result away from the colour specified by the non-fully-transparent texels in the vicinity.
When working on the Wii, I set up a Photoshop script to automatically bleed out colours into transparent regions like this by repeatedly duplicating, blurring, and merging layers (keeping the original on top), and used that as part of my standard export flow.
Note that you can also get similar artifacts if you're using a compressed texture format like DXT-1, which supports only 1-bit transparency, using transparent black as its blending colour. That doesn't appear to be the problem you're encountering here, but this can be worked around too by treating the texture as having pre-multiplied alpha, so the dark fade at the edges gets used as the normal feathering-out of the blending equation, without doubling-up the effect.