You're correct. A consuming application doesn't have anything to do with Reg Z. However, the regulations do dictate the behavior or interface that I can expect from banks, almost like an API contract. It might make more sense if I explain the incident that caused me to add it:
My wife intentionally overpaid on a credit card statement balance in order to gain some credit limit headroom in the current month. Using made up numbers: The balance said we owed $1,000, but she paid $2,000 to make room for a big purchase that month. My application rejected that overpayment as a data integrity error because it would have pushed the credit card balance to -$1,000.
This is a valid state though and Reg Z actually specifies the rules around that case. A bank has to refund a positive balance upon request or automatically after X number of days (I forget the amount).
So now, anytime my agents touch any code associated with credit instruments, they have to run a Reg Z audit to ensure that the data model reflects how banks actually operate in the real world.
My wife intentionally overpaid on a credit card statement balance in order to gain some credit limit headroom in the current month. Using made up numbers: The balance said we owed $1,000, but she paid $2,000 to make room for a big purchase that month. My application rejected that overpayment as a data integrity error because it would have pushed the credit card balance to -$1,000.
This is a valid state though and Reg Z actually specifies the rules around that case. A bank has to refund a positive balance upon request or automatically after X number of days (I forget the amount).
So now, anytime my agents touch any code associated with credit instruments, they have to run a Reg Z audit to ensure that the data model reflects how banks actually operate in the real world.