Thread Safe Bank Transaction: Deposit, Withdrawal, Check Balance and Transfer in Java
Let's break this down.

You have two locks for single object that guarding same fields.

It's generally bad practice, and it doesn't make sense as second lock(transferLock) is used only in single operation. It won't guard for other operations.
It could possibly work if you have a static read-only lock for transfer with the following semantics: add/sub/get are global read lock and transfer is global write lock, then yu should acquire read lock on transfer on regular operations and write-lock on transfer op, but that would allow on;y single transfer at a time, and that's definitely not what you are trying to achieve.

Your locks leak outside of your main class (reed aren't private/protected).

This could lead to uncontrolled use from outside, say future versions of code could misuse locks. I can see that they have package level visibility, that's semi ok, but Account#add,Accound#sub, Account#getBallance are public and not guarded by locks, so that destroys the purpose of haveing locks package-private.
I'd suggest put all usage of locks inside instance methods mentioned above, and add another method:
class Account{
public void transfer(Account other, int amount) { ... }
}

Then all logic related to locking would be in a single, controlled place.

Lock ordering. If you are using granular locks, so no single lock for all accounts and you need to lock several objects you should have STRICT lock order.

You are trying to achieve this with tryLock and while loop, this COULD actually work if you have used your rw lock, but it would be possible to deadlock as you are acquiring other locks then. And it's not really performant to wait in spin-loop here, you can wait forever.
I'd suggest to user your rw-lock but first, sort two accounts by accountId, then take write locks in order of account ids from lower to higher.
//pseudocode
if (acc1.id&lt;acc2.id) {
  acc1.lock.writeLock().lock()
  acc2.lock.writeLock().lock()
}else{
  acc2.lock.writeLock().lock()
  acc1.lock.writeLock().lock()
}

It could be actually combined with tryLock, but it could take a while to acquire such locks.

Minor thing, it's preferable to call unlock() inside finally block, so no objects would stick in a locked state.