The security policy documentation incorrectly states that the inline table value function must have been created using the SCHEMABINDING option. The actual behavior, however, is that the function needs to be schema bound only when the policy is schema bound (default). Since the function with cross-database references cannot be schema bound, the implication is the policy cannot be schema bound either.
Without schema binding, the onus is on you to ensure no breaking changes are made to the function or dependent objects and that the other database is always available. Also, users will need
EXECUTE permissions on the function as well as SELECT on objects accessed by the function (not necessary with
SCHEMABINDING on the function). This may be a security concern depending on the sensitivity of the predicate data.
I think the general best practice is
SCHEMABINDING for the above reasons but you'll need to weigh those benefits with the costs of managing replicated data.
Besides transactional replication, you could use an ETL process or Service Broker to replicate the security policy data. Not sure why the data is in a different database to begin with but another option would be to move the objects to the same database.