There is no way to customize that foreign-key name currently and that is somewhat intentional.

The FK relationship you shown is just one of many different relationships that get built automatically as a part of the Envers metadata model. In order to do this properly, we need to consider all avenues.

1. DefaultAuditStrategy: REV column -> REVINFO.
2. ValidityAuditStrategy: REV column -> REVINFO and REVEND column -> REVINFO.
3. Potentially others between audit tables
4. What about those added by custom AuditStrategy implementations?

In general the accepted practice has traditionally been to let Envers build its schema. From there export the schema to a script and supply that as a part of your Flyway/LiquidBase/etc migration strategy.

Hopefully going into 6.0, there will be some new Schema Migration tooling improvements that will allow you to be able to specify how schema migration happens per component level. For example, you could have ORM tables set to validate while you would allow the Envers tables to be set to update, therefore allowing Envers to morph as it deems necessary if you wanted.

I could see an annotation that perhaps would work solely for (1) and (2). Another annotation could be introduced to handle the potential use case of (3) if such a case exists. As for (4), that's what I am unclear on.