“Cards stay above the new policy limit because the sheet was not pushed to the issuer”
Manual Data Flow Trap
1
Edited
Limit Edited
Finance lowers a limit on the policy tab.
2
Not Pushed
Issuer Unchanged
The sheet is not uploaded to the issuer.
3
Over Limit
Spend Continues
The card still authorizes above the new policy.
Root Operational Bottleneck
Corporate card policy limits are edited in a workbook that is supposed to be sent to the issuer, so a lowered limit stays on the card until someone uploads the sheet.
Control Hazard & Audit Exposure
Cards stay above the new policy limit because the sheet was not pushed to the issuer, and spend continues on a limit the policy already revoked.
Manifests in: Card-policy workbook and issuer-limit change log
Deterministic Replacement (After)Golden Door Standard
Target Software Architecture
Card-Policy Registry that Pushes Limit Changes to the Issuer Before the Next Cycle
Deterministic Pipeline Execution
1
Versioned
Policy Version
Each limit change is stored with an effective date.
2
Pushed
Issuer Push
The new limit is written to the issuer before cycle start.
3
Gated
Cycle Gate
A mismatch keeps the cycle from opening.
Deterministic Software Pattern
Card-policy registry that versions each limit change and pushes it to the issuer before the next billing cycle can open.
Continuous Assertion Rule
Limit assertion: a card cycle cannot open if the issuer limit differs from the policy version in force on the cycle start date.
Corporate card policy limits are edited in a workbook that is supposed to be sent to the issuer, so a lowered limit stays on the card until someone uploads the sheet.
Control Hazard & Audit Exposure
Cards stay above the new policy limit because the sheet was not pushed to the issuer, and spend continues on a limit the policy already revoked.
Deterministic Replacement (After)Golden Door Standard
Target Software Architecture
Card-Policy Registry that Pushes Limit Changes to the Issuer Before the Next Cycle
Deterministic Pipeline Execution
1Policy Version
Versioned
Each limit change is stored with an effective date.
2Issuer Push
Pushed
The new limit is written to the issuer before cycle start.
3Cycle Gate
Gated
A mismatch keeps the cycle from opening.
Software Pattern
Card-policy registry that versions each limit change and pushes it to the issuer before the next billing cycle can open.
Continuous Assertion Rule
Limit assertion: a card cycle cannot open if the issuer limit differs from the policy version in force on the cycle start date.
Related problems
Same AP & Expense catalog · unique PCF · stay on directory
“Cards stay above the new policy limit because the sheet was not pushed to the issuer”
Manual Data Flow Trap
1
Edited
Limit Edited
Finance lowers a limit on the policy tab.
2
Not Pushed
Issuer Unchanged
The sheet is not uploaded to the issuer.
3
Over Limit
Spend Continues
The card still authorizes above the new policy.
Root Operational Bottleneck
Corporate card policy limits are edited in a workbook that is supposed to be sent to the issuer, so a lowered limit stays on the card until someone uploads the sheet.
Control Hazard & Audit Exposure
Cards stay above the new policy limit because the sheet was not pushed to the issuer, and spend continues on a limit the policy already revoked.
Manifests in: Card-policy workbook and issuer-limit change log
Deterministic Replacement (After)Golden Door Standard
Target Software Architecture
Card-Policy Registry that Pushes Limit Changes to the Issuer Before the Next Cycle
Deterministic Pipeline Execution
1
Versioned
Policy Version
Each limit change is stored with an effective date.
2
Pushed
Issuer Push
The new limit is written to the issuer before cycle start.
3
Gated
Cycle Gate
A mismatch keeps the cycle from opening.
Deterministic Software Pattern
Card-policy registry that versions each limit change and pushes it to the issuer before the next billing cycle can open.
Continuous Assertion Rule
Limit assertion: a card cycle cannot open if the issuer limit differs from the policy version in force on the cycle start date.
