Flexible Fees, Governed Changes

A fee schedule is a business policy, not just a percentage. The same amount may attract different charges at an ATM, at a contactless terminal, or online. A merchant category may carry a surcharge. Small transactions may need a floor, large ones a ceiling. Several independently disclosed charges may apply together.

Hard-coding each variation turns pricing changes into software releases. Making everything freely editable creates a different problem: one configuration change can affect every transaction on a product. jCard brings these concerns together—expressive pricing rules, a controlled approval lifecycle, and evidence of what was actually charged.

Policy without another transaction branch

A fee definition separates when it applies from how much it charges. Its family, currency, amount band, date window, and trigger conditions narrow its scope. A formula computes the charge from a fixed, typed set of transaction and configuration facts.

That supports flat charges, percentages, floors, ceilings, and conditional pricing within the same model. For example, a USD fee of thirty cents plus two percent, bounded between fifty cents and five dollars, can be expressed as:

min(max(30 + amount * 2 / 100, 50), 500)

The numbers are minor units, not floating-point dollars. Currency exponents and defined rounding keep the calculation consistent. Channel, merchant category, and transaction type let a policy distinguish a purchase from a cash withdrawal without adding a new branch to the authorization code.

Matching fees are additive. A base charge and a channel surcharge can remain separate definitions rather than becoming one increasingly complicated formula. Named sets provide another useful separation: a formula can refer to a governed list of merchant categories instead of embedding dozens of codes in its expression.

This is flexibility inside a defined boundary. Expressions are compiled and type-checked, their size and evaluation cost are bounded, and applicable amount-based formulas have a configurable percentage cap. They are not arbitrary scripts with access to the application. Message-supplied facts can affect pricing; they do not replace card, PIN, limit, or tenant checks.

Four eyes on the policy—and its dependencies

The important control is not a confirmation dialog. It is the distinction between authoring and certifying.

An operator saves a draft. Under the normal four-eyes policy, a different authorized person must certify it before it can charge anything. Author and approver entity roles are separated, and enforcement lives on the server, not just in the visibility of a button. The platform's explicit break-glass override is audited; it is not the routine approval path.

The reviewer sees the server's sample calculations across amounts and relevant contexts, including caps and errors. That makes the practical effect of a formula visible alongside its text. A sample grid is not proof of every possible input, but it makes review more concrete than approving an expression in isolation.

Certification seals the pricing content. The calculator checks that seal as well as the certified status, so changing a database row without changing its status does not preserve approval. A legitimate edit also invalidates the old approval: the fee returns to draft and stops pricing until it is certified again. There is no implicit promise that the old live version keeps running while someone edits its replacement.

Named sets follow the same governance because changing a list can change a fee without touching its formula. A set referenced by a certified fee cannot simply be edited or retired underneath it. The dependency is part of the controlled change.

Keep the explanation attached to the money

A total tells an operator what the customer paid. It does not necessarily explain why.

With the current fee-aware posting templates, each charged fee has its own ledger entry, labelled and tagged with its identity and, when sealed, a certification fingerprint. A base fee and two surcharges remain distinguishable even when they credit the same fee-income account.

Subsequent lifecycle postings use the original fee breakdown rather than reinterpret the transaction using today's schedule. That matters when investigating a reversal after pricing has changed: the accounting evidence should describe the original charge, not a new calculation. Older entries and older template versions retain their previous aggregated representation.

AI helps write; people approve

Optional AI assistance can propose a formula or explain it. A proposed formula must compile before it is offered as a usable expression, and the sample grid remains a server calculation—not a model's estimate.

The model neither saves the fee nor certifies it. The operator still creates a draft, and an independent approver still reviews it. Runtime pricing does not call the model.

That is the point of the design: make business policy easier to express without making it easier to change unnoticed. The video shows the workflow; the combination of bounded formulas, independent certification, protected dependencies, and ledger attribution makes that workflow usable in operations.