Stata uses double or float representations of numbers (i.e. base 2 not base 10). Unfortunately for you, 1.015 is not representable in base 2, so it goes to the nearest value which in this case is slightly less than 1.015, so the round goes down. This is a common issue when dealing with floating point precision on computers - see for example this question in Ruby: Ruby Float#round method behaves incorrectly with round(2)
So how do you fix it?
If 3 decimal places of precision are important to you, you need to use fixed point precision. I don't believe Stata supports this natively, but it's easy enough to do it yourself:
display round(1015, 10)*0.001
i.e. your input numbers get multiplied by 10^3, and your displayed numbers get multiplied by 10^-3. All the processing is therefore carried out with integer precision at the number of decimal places you're interested in.
Note, however, that the seemingly equivalent display round(1.015*1000, 0.01*1000)*0.001
would not work, because the base-2 rounding will have already occurred when reading "1.015" (i.e. the computer would see 1.01499999...*1000 = 1014.999...). Of course, this also applies if you are getting the value 1.015 from elsewhere, such as user input or reading a file.
As an aside, Stata seems very quiet on its rounding mode (also known as tie-breaking). While it's likely that it uses ties-up, it could also be ties-to-even or other options - it's best not to rely on precise half-way behaviour unless you can find an explicit spec for it.
display %23.18f 1.015
to see that 1.015 can't be held exactly as such; what you report is a side-effect.search precision
in Stata for enormously more discussion. – Nick Cox