It's not okay, because fields (even final ones!) may not have the value you expected them to be. A bit of a chicken-and-egg scenario: Your method would presume that the object is fully constructed, and yet, it is not possible to fully construct the object until the method is done.
The usual go-to alternative is static methods. This avoids the entire hullabaloo. This does mean you have to pass in the actual bits of information you need to run this calculation, but that's actually a good thing: It makes it clearer which info is needed, and easier to test.
I notice that your fields aren't final; I assume that the calculation to determine 'premium' depends on at least one of these non-final fields. In that case, have you thought about what happens when that field is updated? Generally, the easiest way to solve this problem is to make all the fields final, and make this an immutable object, neatly sidestepping the 'but what if this is updated?' issue.
A second easy solution is to remove the premium field entirely and recalculate it every single time. If it's all math (some multiplying and application of exponents and logs and the like), well, CPUs are incredibly fast. In fact, a CPU can do 300 to 500 instructions in the time it takes to do a single memory lookup (I'm VASTLY oversimplifying, as a memory lookup of an adjacent field is usually from the same cache page and therefore effectively free, but, hey, if it had to fetch that cache page in the first place, once we're already 500 cycles in, why worry about another 4 cycles, right? Maybe having this object take one double worth of memory less actually saves a cache lookup later, and is thus faster – without profiler reports, don't guess, go for the code that is simpler to write, and getting rid of premium
entirely sounds like it'd be simpler here. Have everybody call getPremiumByCalculation() every time (and rename it just getPremium()).