> I even have specialized agents doing audits against Regulation Z (US banking law) criteria so the app models the required behavior of banks.
Can you elaborate on this? Clearly you cannot imply this means those audits have any real value since its just roleplay in this context right? Because your app in the current form will not be affected by Regulation Z in any way.
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.
Can you elaborate on this? Clearly you cannot imply this means those audits have any real value since its just roleplay in this context right? Because your app in the current form will not be affected by Regulation Z in any way.