Issuer Processing Platform
Cards · Accounts · Limits · Holds
The answer the switch is waiting for.
Decided, held, and recorded.
bRUID BIPS is the issuer side of the estate. It holds the cards and the accounts, decides every authorization against card status, expiry, currency, per-transaction and daily limits and available balance, and places an atomic hold the moment it approves. Reversals are matched to the transaction they reverse and release exactly what was held.
From bRUID BAPS · ISO 8583
Same transaction as the balance check
Checked in order on every request
No double-spend under concurrency
Standards-aligned result codes
Every authorization runs the same chain. A decline names the control that refused it, so "why was this declined" has an answer rather than a theory.
Does the card exist, is it active, and is it neither blocked nor reported lost or stolen?
Is the card still in date? An expired card is refused before anything touches the account.
Does the linked account exist and is it in good standing? A blocked account declines regardless of card state.
Does the transaction currency match the account currency? A mismatch is refused rather than silently converted.
Is the amount within the per-transaction ceiling, and does the day’s accumulated total stay inside the daily limit?
Is there enough available balance — ledger less every open hold — and if so, place the hold atomically.
An approval places its hold in the same database transaction that checks the balance. Two authorizations arriving at once on the same account cannot both pass the same available figure - one of them waits, sees the other's hold, and is decided against the truth.
Available is always the ledger balance less every hold that is genuinely open. Holds are released when the reversal that matches them arrives, not on a timer and not on trust.
A settlement moves money out of the ledger. A reversal releases a hold. Only these two change the picture — an authorization that was never answered does not quietly expire into someone's spending power.
Treating them as the same message is one of the quietest and most expensive mistakes in card processing. BIPS handles them as the two different things they are.
Cancels an authorization that has not settled. It is matched against the original on terminal, trace number, transmission time and amount, and releases exactly the hold that was placed.
An unmatched reversal is declined, not credited. Trusting the amount a reversal claims is how an issuer gives money away to a message it never authorized.
A new financial transaction with its own identity, moving money to the cardholder. It is not matched against an original, which is exactly why a merchant can refund partially and more than once.
A refund is deliberately not balance-checked. Applying a funds test to a credit would decline exactly the refunds a cardholder needs most.
Cards, accounts, statuses, expiry, credit limits and per-card transaction and daily ceilings, all editable while the platform is running. Card numbers are validated on save, so an unusable number is refused at entry rather than surfacing later as a gateway fault.
Result codes follow the jPOS Common Message Format, and every code the platform can return has a matching mapping at the acquiring switch. A code that cannot be mapped reaches the merchant as a generic failure, so the set is kept closed on purpose.
Any card can be scripted to approve, hard decline with a chosen code, delay its answer or stay silent — so the timeout, retry and store-and-forward paths through the rest of the estate get exercised before a certification run rather than during one.
Every request and the answer given, with the control that decided it, queryable by card, state or time. Support questions are answered from the record, not reconstructed from logs.
Cards, accounts, holds and the transaction log are persisted rather than held in memory. A restart mid-run does not reset balances or lose the record of what was authorized.
Every authorization with its result code and plain-language meaning, the card and account deck, open and released holds, and the outcome mix across recent traffic.
Balance and hold invariants are enforced by the database, not only by the application. A bug in the decision path can decline something it should have approved; it cannot create money.
ISO 8583 from the switch
The six-control chain
Status, expiry, ceilings
Ledger and available
Atomic place and release
Original lookup by key
Refunds as new credits
Scripted behaviour
Every request and answer
Liveness and outcome mix
The side of the transaction that owns the money.
Balance rules enforced below the app
Check and hold in one transaction
bRUID Kms managed
Every request and its answer
Cards, accounts, limits and holds on one platform — with the reversal and refund handling that keeps a ledger honest.