fincarna

Fee income your billing system can actually express

Non interest income is under real pressure, and the answer is smarter relationship based pricing. That only works if your billing layer can execute it.

The challenge

Fee income is a large share of what an institution earns, and it is under structural pressure from both regulation and competition. The strategic response is well understood. Move away from punitive flat fees and towards pricing that reflects the depth of the relationship.

The obstacle is not strategy. Every institution we speak to already knows what it wants to charge. The obstacle is that the billing layer inside a core banking system was built when products changed once a year, promotional pricing was a rare exception, and a fee schedule was something you printed.

So pricing that the business designed gets simplified down to what the system can do. Waivers become permanent flags because there is no lifecycle. Tier thresholds get approximated because the calculation is not expressible. Every genuinely relationship aware idea becomes a manual process, and manual processes are where revenue quietly leaks.

How Fincarna solves it

Fincarna adds the layer your core is missing. Fee schedules, entitlements, waivers, rewards, and promotions are configured objects with lifecycles, not exceptions handled by hand each cycle.

The catalog is built for this. One product can carry several pricing variants. Variants group into bundles. Rewards and promotions sit on top. Everything is versioned and effective dated, so you can schedule a change, run a campaign, and answer precisely what the pricing was on any given day.

Every cycle the engine executes those rules and records how it reached each number. Your core keeps the ledger and the regulatory reporting. Fincarna decides what to charge and can always show its work.

LAYER 1ProductMirrors what exists in your coreYour core has products. So does Fincarna.Chequing, savings, LOC, mortgage. One-to-one with your core.LAYER 2VariantsMultiple pricing models per productOne product, many pricing options.A LOC can have Standard and Premium variants, each with itsown fees, rates, entitlements, and billing cycle.LAYER 3aBundlesGroup variants, price as oneGroup variants across products into asingle offering with shared pricing.LAYER 3bRewardsConditional, behavior-drivenWaive fees or discount rates whenconditions are met. Encourage behavior.LAYER 4aPromotionsTime-limited, rule-drivenTake any variant or bundle to market.Set a window. Everything reverts on expiry.LAYER 4bDealsNegotiated, per clientBespoke terms for one relationship.Approved before they ever reach a bill.Your core todayProductflexibilityRelationshippricingCompetitiveadvantageEach layer adds capability your core doesn't have. No migration required.WHAT IT ENABLES ↑

What you can charge for

01

Balance aware fees

Not flat subscriptions

Waive the monthly fee above an average balance, charge it below one, and define precisely which average you mean. Daily, monthly, minimum, or a formula of your own. The ambiguity in the phrase average monthly balance is where a surprising amount of revenue goes missing.

02

Entitlements and overage

Free, then billed

Give an account a number of free transfers, withdrawals, or ATM transactions per cycle and bill automatically once they are used up. The counter resets with the cycle without anyone driving it.

03

Waivers that actually expire

Lifecycle, not a flag

A waiver has a start, an end, and a reason. When it ends it stops applying. Waivers that were granted once and never revisited are one of the most common and least visible sources of revenue leakage.

04

Household and bundle pricing

Priced as a relationship

Group accounts into households and bundles, share benefits across them, and control how charges and waivers are distributed across the relationship rather than pretending each account exists alone.

Key capabilities

A catalog with room for pricing

Products mirror what your core already knows. Variants let one product carry several pricing models. Bundles group variants into relationship packages. Rewards and promotions layer on top. Each layer adds something your core was never asked to do.

Variants versioned and effective dated

Change a fee schedule without rewriting the product. Every variant revision carries its own effective date, so you can schedule a change in advance and answer later what the pricing was at any point in time.

Promotions with a real lifecycle

Eligibility, enrolment, stacking rules, and automatic expiry are part of the promotion rather than manual steps around it. When a campaign ends the pricing reverts on its own, which is the whole point.

Rewards driven by behaviour

Discount a rate or waive a fee when conditions are met, and recalculate tier status each cycle as the relationship changes. Benefits follow what the customer actually does rather than what they qualified for a year ago.

Custom logic where you need it

Most pricing is configuration. For the genuine edge cases, write a rule in JavaScript that runs inside the billing engine, with your own custom fields available as first class properties on the customer and account.

An audit trail on every charge

For any amount on a statement you can retrieve the inputs, the rule that fired, the output, and the account it applied to. Not a log line saying a fee was charged, but the full calculation.

Your pricing logic, your vocabulary

Fincarna ships with core objects: accounts, customers, events, and products. Every institution is different, so you can extend any of them with your own properties through the dashboard, the API, or a column in a file.

Those extensions are not just metadata. The pricing engine has full access to every custom field you define. Extend the customer object with a loyaltyTier property and it is immediately available as customer.loyaltyTier in your billing rules.

Most pricing never needs code at all. When an edge case genuinely does, it reads like the business rule it represents.

Fincarna extensible data model showing custom event attributes

Leakage patterns we eliminate

Zombie waivers

Fee waivers granted during account opening that were never set to expire. Fincarna tracks every waiver with an explicit lifecycle. Waivers without an expiry date are flagged. When conditions change, Fincarna automatically revokes them.

Tier miscalculation

"Average monthly balance" can mean different things depending on who configured it. Fincarna calculates balances using your exact rules (daily average, monthly average, minimum, or any custom formula) and applies the correct tier assignment consistently across every account.

Stale fee schedules

Fee schedules change, but configurations don't always keep up. Fincarna maintains a single source of truth for your fee schedules. Every charge is calculated from the current rules, delivered in real time or on your billing cycle.

Promotional rate overrun

A promotional rate was supposed to end after 90 days. The marketing campaign stopped, but the billing adjustment is still active. Fincarna manages all promotional rates with hard expiry dates. When the promotion ends, the rate reverts.

Unbilled service fees

Wire transfers, certified cheques, and foreign currency conversions that should incur a fee but don't, because the billing event was never configured. Fincarna maps every billable event to a fee rule and flags the gaps.

What changes

1–5%
Revenue at risk in legacy billing

Fincarna eliminates the gaps by executing your pricing rules directly

Every cycle
Billing enforcement

Every account, every charge, calculated automatically from your current rules

Full
Audit trail

Every pricing decision is auditable: the rule, the account, the amount, and why it was applied

Bring the fee you cannot currently charge

Most teams have one. The calculation the core cannot express, so it never shipped. That is the most useful thing to put in front of us.

or email us at hello@fincarna.com