BRD - Everyday Payment Account Plus
1. Product objective
This document describes the product conditions for a retail payment account controlled by LimitRail. The account must support everyday operations, understandable fees, controlled limits, customer-selected thresholds and auditable operational exceptions.
LimitRail does not open accounts, generate IBANs, execute payments, update the ledger or calculate accounting balances. The calling system owns those processes and sends verifiable facts to LimitRail: opaque account reference, operation code, amount, currency, timestamp and contextual policy data. LimitRail decides which policy applies, whether the operation may continue, which limits are consumed, which fees are produced and how the decision is explained.
The product is called Everyday Payment Account Plus. The scope is intentionally limited to one product, but it includes enough cases to demonstrate the main engine capabilities: fixed fees, percentage fees, explicit no-fee rules, tiered fees, amount and count limits, period limits, dimension-split limits, customer-selected limits, runtime metadata conditions, account-attribute conditions, segments, account deals and operational exceptions.
2. Governed operations
The product uses stable operation codes agreed with the calling system. The calling system sends these codes at runtime; it must not send pre-interpreted commercial categories.
| Operation code | Business meaning | Policy use |
|---|---|---|
ACCOUNT_FUNDING |
Incoming account funding or top-up | Resulting balance limit, monthly volume and lifetime volume. |
SEPA_OUT |
Standard outgoing SEPA transfer | Single, daily and monthly limits; yearly included allowance. |
SEPA_INSTANT_OUT |
Instant outgoing SEPA transfer | Dedicated fixed fee and shared outgoing transfer limits. |
ATM_WITHDRAWAL |
ATM withdrawal | Daily amount and count limits; monthly included allowance. |
P2P_PAYMENT |
Digital P2P payment | No fee below threshold, fee above threshold and monthly limit. |
CARD_PURCHASE |
Card purchase | Explicitly free operation. |
INTERNATIONAL_TRANSFER |
Extra-SEPA transfer | Percentage fee with minimum/maximum and country-split limits. |
MONTHLY_MAINTENANCE |
Monthly account maintenance | Fee driven by average monthly balance. |
TRANSFER_RETURN |
Operational return or recall | Own fee when required, separate from technical counter reversal. |
3. Limit rules
Limits are control rules. A blocking rule prevents the operation when the threshold is exceeded; a non-blocking rule produces a warning without stopping the external process.
Incoming funding
The resulting balance after a funding operation must not exceed EUR 2,400. The
calling system must send resulting_balance_after_operation, meaning the
projected balance after the requested operation. LimitRail uses this value to
decide whether the product would remain within the allowed threshold.
Total incoming funding must not exceed EUR 4,000 per month and EUR 75,000 over the account lifetime. These two limits consume counters: each confirmed operation increases the relevant period consumption.
Outgoing SEPA transfers
A single SEPA_OUT transfer must not exceed EUR 1,250. Total outgoing SEPA
amount must not exceed EUR 2,750 per day and EUR 9,000 per month.
The customer may choose a stricter personal daily SEPA limit, for example EUR 900. The customer threshold must never exceed the product maximum. When active, LimitRail uses the customer threshold before the standard threshold.
Standard and instant outgoing SEPA transfers must share the overall outgoing
transfer limit. To achieve this, the product treats both operations as part of
the same SEPA_OUTGOING operational channel for counter purposes.
ATM withdrawals
Total ATM withdrawal amount is limited to EUR 450 per day. The account may also execute at most 4 ATM withdrawals per day. The product allows the customer to choose a lower daily ATM threshold, for example EUR 200, within the product boundaries.
P2P payments
Total monthly P2P_PAYMENT amount must not exceed EUR 3,500. The rule is
blocking and consumes the monthly counter for this account and operation.
International transfers
INTERNATIONAL_TRANSFER has a monthly account limit of EUR 5,000. The product
also wants to split consumption by destination country, so the current usage can
be inspected and governed by destination_country. The calling system sends
destination_country as a transaction fact.
4. Pricing rules
Fees must be calculated by LimitRail, not by the calling system. The caller must not send values such as "standard fee", "free operation", "threshold exceeded" or "discounted customer". It sends the required facts and LimitRail applies the rule.
Explicit free operations
CARD_PURCHASE is free. The product wants this inclusion to be explicit in the
response and in audit, so a pricing rule returns a zero fee.
Fixed fees
SEPA_INSTANT_OUT has a fixed fee of EUR 0.80 per operation. TRANSFER_RETURN,
when modeled as a separate operational event, has a fixed fee of EUR 0.30.
Percentage fee with minimum and maximum
INTERNATIONAL_TRANSFER has a fee of 0.35% of the operation amount, with a
minimum of EUR 1.50 and a maximum of EUR 12.00. LimitRail calculates the
percentage on the received amount and then applies the minimum and maximum.
Tiered included allowance
The first 10 SEPA_OUT transfers per year are included. From the 11th standard
transfer onward, each operation is charged EUR 0.60.
The first 6 ATM withdrawals per month are included. From the 7th ATM withdrawal onward, each operation is charged EUR 0.90.
These rules must be based on usage counters. The calling system must not tell LimitRail whether the allowance is exhausted: LimitRail derives it from confirmed consumption and active reservations.
Fee above amount threshold
P2P payments are free up to EUR 75. If the single payment amount is above EUR
75, a fixed fee of EUR 0.40 applies. The calling system only sends amount;
LimitRail decides which pricing rule applies.
Monthly maintenance fee
Monthly maintenance depends on average monthly balance. If
average_monthly_balance is at least EUR 200, no maintenance fee applies. If it
is below EUR 200, a EUR 0.70 fee applies.
LimitRail does not calculate the average balance from transactions. The value must be supplied by the system that owns balances or by the periodic process that calculates the maintenance fee.
5. Policy data
Some data is automatic: operation code, channel, product, segment, currency, amount and account status. Other data must be configured as policy inputs.
| Data | Source | Use |
|---|---|---|
resulting_balance_after_operation |
Runtime metadata | Block funding that would exceed maximum balance. |
average_monthly_balance |
Runtime metadata or periodic process | Decide whether monthly maintenance applies. |
destination_country |
Runtime metadata | Apply rules and split counters by country. |
transfer_speed |
Runtime metadata or operation attribute | Distinguish standard and instant transfer when using a shared model. |
customer_tier |
Account attribute | Trigger premium conditions, discounts or account deals. |
residency_country |
Account attribute | Apply residency-driven constraints or pricing. |
regulatory_status |
Account attribute | Block or tighten policy for accounts under review. |
Policy data must be raw, controlled facts. It must not be a commercial decision already taken by the caller.
6. Segments, account deals and exceptions
Segment is optional. It is used when the same product must apply a different
policy to a category of accounts, for example RETAIL, PREMIUM or
BUSINESS. If no segment assignment exists, the product policy applies.
An account deal is a policy assignment for a single account. It is used for negotiated or exceptional conditions, for example a premium customer with lower international transfer fees for an agreed period. The account deal is governed by backoffice; it is not a field sent by the integrator during account registration.
A policy exception is different from a customer threshold and from an account deal. A customer threshold makes a limit stricter. An account deal changes the policy applicable to an account. A policy exception allows or traces a temporary controlled bypass of a blocking rule, with reason, validity and audit.
Example: a funding operation would bring the balance to EUR 2,500, above the standard EUR 2,400 maximum. Operations may approve a temporary policy exception up to EUR 2,600. LimitRail must show that the operation passed because of the exception, not because the standard policy changed.
7. Pricing composition
When multiple pricing rules apply to the same request, the product must define how they are composed.
Additive mode sums base fees and surcharges. For example, a transfer base fee plus an extra-SEPA country surcharge.
First match mode selects the first valid rule by priority. It is useful when rules are alternatives and the business order is explicit.
Best price mode selects the lowest fee among alternative rules. It is useful for promotions or premium conditions, for example a EUR 0.60 standard rule and a premium zero-fee rule.
Highest price mode selects the highest fee. It is useful only when the product wants the most conservative condition among alternatives.
If a selected pricing group must prevent later groups from adding fees, the product must stop composition after that group. This avoids a promotion or waiver being charged again by later unwanted fees.
8. Success criteria
The configuration is correct when LimitRail can:
- recognize all product operation codes;
- apply single, daily, monthly, yearly and lifetime limits;
- calculate fixed, percentage with min/max, explicit no-fee and tiered fees;
- distinguish conditions based on runtime metadata and account attributes;
- enforce customer-selected thresholds without exceeding product boundaries;
- manage segments and account deals without letting the integrator choose the policy;
- apply temporary auditable policy exceptions;
- explain which rules decided, which data was used and which counters were consumed.
The expected output is not a perfect technical configuration on the first try, but a complete, verifiable and editable policy draft before publication.