Custom ResponseModel for Spring Controller - ResponseEntity
To start, I think what you have there looks pretty straight forward.  It also looks very neatly written.  From just what I can see here, it would appear the largest gain from your "base" model is that it removes extraneous data from traveling out to the user.  The largest loss (potentially), is that it utilizes inheritance and theoretically forces those 4 properties onto every inherited result.  That being said, here's some reasoning...

Disclaimer :) Inheritance may be the perfect solution for what you've got going here in the long run.  But from the limited view here, it feels heavy handed.  It should also be noted that I haven't written Java an about 9 years and I'm currently a C/F# programmer.

Two things stand out to me.  First, the use of properties and private fields.  This contract appears to be immutable.  Could the fields just become public and final and lose the setters?  It doesn't appear to do much except to protect inherited members from accessing those values directly.  It would also reduce the amount of code in the class (#1 reason).  I can't see from here what the benefit of them being private is.  The notion that an inherited class would have no real access to it's base class raises a red flag.

This leads to the second thing.  Consider removing the inheritance.  Inheritance is always great until it's not.  You contract is simple enough that it wouldn't suffer this problem today, but several inherited types later it might.  The challenge with inheritance (especially with data), is that it forces everything to be the same shape.  The upside, is that inheritance is never really required to solve a problem.  It's just something we do... just because, usually.

You could consider a setup like this (pseudo code):

public class TransactionResponseModel { ... }

public class BalanceInquiryResponseModel {
    public BalanceInquiryResponseModel(TransactionResponseModel transactionResponseModel, BalanceInquiryResponse balanceInquiryResponse) {
    ...
    }

    public final TransactionalResponseModel TransactionalResponse;
    public final BalanceInquiryReponse InquiryResponse;
}


Inheriting doesn't really force anything, because the next developer might simply choose not to inherit.  Here you get all the same shapes and data without the class coupling and hierarchy.  Which is, in my experience, totally worth it.  When the response model comes that doesn't fit the same shape as your base classes, you won't have to setup a new inherited structure, modify your current one, or even care for that matter.  New data, new shape, no problem.

There are lot's of articles available on the un-benefits of inheritance:

Gooooooooogle

Hope this information is helpful.