ptenes
Talk to an engineer

use cases

Reference architectures.

How to build with the blocks: each case shows who it is for, the problem, the build and what you get. These are not case studies — they are architectures you can copy.

6 architectures · six blocks · seven rails

01

Full digital bank

who it is for

IPs and SCDs — Brazil's payment-institution and direct-credit-company licences — and digital banks (S2–S4) launching their own accounts, Pix and card issuing.

Launching accounts, transfers and Pix from scratch takes a correct ledger, real-time risk control and a connection to BACEN, Brazil's central bank — usually months of wiring separate systems together.

the build

  1. Midazthe double-entry ledger where everything settles
  2. Tracervalidates every transaction in real time, before the ledger
  3. Flowkerorchestrates onboarding, approvals and routing
  4. SPI · Pix / SPB · TEDsettlement direct at BACEN
  5. Reporterregulatory reports straight from the ledger

what you get

  • A ledger that is correct by construction, in double entry and with an immutable trail.
  • Pix and TED settling directly, with no third-party gateway.
  • Risk and compliance in the same stack, not bolted on as add-ons.
build this architecture →

02

Embedded finance / BaaS

who it is for

BaaS providers and platforms serving several brands or subsidiaries.

Serving several brands from one base takes full tenant isolation, events each client's systems can consume, and a connection to payments — without duplicating infrastructure.

the build

  1. Midaz (multi-tenant)one ledger with full isolation per tenant
  2. Flowkeronboarding and payment routing per brand
  3. Pix / TED pluginspayments connected through an interface
  4. Access Managercentralized authentication and identity
  5. Reporterstatements and reports per brand

what you get

  • Full tenant isolation from the foundation up.
  • Domain events published on every movement — each client's systems react from there.
  • One infrastructure base, many brands.
build this architecture →

03

Marketplace

who it is for

Commerce platforms that sit in the middle of the payment between sellers and buyers.

One payment turns into several destinations at once — seller, commission, shipping, withholdings — and they all have to settle atomically or none of them settle.

the build

  1. Midazone account per seller and an atomic multi-party split
  2. Flowkerorder → payment → balance release
  3. Tracerapplies rules and limits before the payout
  4. SPI · Pixseller inflows and payouts at BACEN
  5. Matcherreconciles the PSP against the ledger
  6. Reporterseller statements and tax reports

what you get

  • Seller, commission, shipping and withholdings in a single transaction: everything settles, or nothing does.
  • Per-seller balances in the ledger itself — no side spreadsheet.
  • Differences against the PSP isolated as exceptions, not surprises.
build this architecture →

04

Acquiring and sub-acquiring

who it is for

Acquirers, sub-acquirers and payment facilitators.

Every real captured breaks down into MDR (the merchant discount rate), the network fee, the acquirer fee and the merchant's net — components that settle anywhere from D+1 to D+30, and the payout still has to leave on time.

the build

  1. Midazevery fee component with an entry of its own
  2. Matchersettlement files with tolerance and 1:N split matching
  3. Flowkercapture → settlement → payout
  4. Tracerbusiness rules before authorizing
  5. SPI · Pix / SPB · TEDmerchant payout at BACEN
  6. Lenderreceivables advances, booked in the ledger

what you get

  • MDR, network, acquirer and net each with an entry of their own — not one net figure with no arithmetic behind it.
  • The settlement file checked against what was captured, with tolerance for fees and timing.
  • Payouts by Pix or TED direct at BACEN, with no intermediary in the money path.
build this architecture →

05

Consignado (payroll-deducted lending)

who it is for

Consumer finance companies, SCDs and credit fintechs running consignado — lending repaid straight out of the borrower's payroll — in Brazil.

Running consignado goes from origination and signing the CCB (Brazil's standard loan note) to averbação at Dataprev, the registration that makes the payroll deduction happen, and on to booking every event — usually spread across systems that do not talk to each other.

the build

  1. Lenderorigination, CCB, servicing end to end
  2. Consignado · Dataprevaverbação (payroll registration) and the operations exchanged
  3. Midazbooks every credit event
  4. Reporteraccounting and regulatory reports

what you get

  • From proposal to averbação — the payroll registration — in a single engine, with one consistent history.
  • Every financial event booked in the double-entry ledger.
  • End-to-end consignado coverage, in one stack.
build this architecture →

06

Enterprise reconciliation & treasury

who it is for

Enterprise treasuries and back-office teams that close the month without replacing their core.

Closing the month by checking statements from banks, processors and ERPs against internal records eats days in spreadsheets — and you want that solved without replacing the core you already run.

the build

  1. Matcherreconciles the sources you already have, with scores
  2. Flowkerorchestrates the cycle, from ingestion to close
  3. Reporterreconciliation and variance reports

what you get

  • Automatic reconciliation across banks, processors, ERPs and ledgers.
  • Runs standalone on top of the systems you already have — no core migration.
  • Exceptions routed to JIRA or ServiceNow, through webhooks.
build this architecture →

Which architecture is yours?

Bring us your case — we assemble it from the blocks.

Talk to an engineerSee the platform