Direct connections to banks, schemes and payment rails

Every transaction pays a middleman for a connection to the bank or the scheme, and their release schedule decides what you can launch.

Symptoms in your system

  • Per-transaction fees to an aggregator now cost more than the engineers it would take to connect directly.
  • Your bank moved to ISO 20022 and your integration still speaks the flat file format it replaced.
  • ACH returns come back as a file nobody parses, so failed debits are discovered by the finance team.
  • Instant payments went live in your market, and customers ask why a transfer still lands the next business day.
  • Sub-merchant onboarding runs through a portal you do not own, and every new merchant waits on a partner to approve it.

What we build

  • You hold the connection to the bank and the scheme, so pricing and new products stop depending on a provider roadmap you cannot influence.
  • Card authorization, capture and reversal run over your own ISO 8583 link, and a partial reversal at the terminal arrives as one event the ledger already understands.
  • ACH files leave inside the window your bank enforces, and a NACHA return code posts against the original debit instead of landing in an inbox.
  • SEPA and SEPA Instant payments run on one model, so a euro payout behaves the same whether it settles in seconds or on the next cycle.
  • FedNow and RTP payments are answered while the customer is still on the screen, rejects included, so nobody is left watching a pending status.
  • Sub-merchant onboarding, split payouts and settlement run on your platform, and we build what an acquirer asks to see before it registers a payment facilitator.

Failures that surface a year later

  • One acquirer and no second route, so an outage on their side is an outage on yours and the fallback gets designed during the incident.
  • Scheme mandates handled as a yearly one-off project, so every card flow is re-tested from scratch each time one lands.
  • Aggregator pricing agreed at launch and never reopened, so every unit of growth raises the bill in a straight line.
  • Payfac registration treated as paperwork at the end, after the platform is already built on assumptions the acquirer will not accept.
  • Open banking consents that expire quietly, so a subscription stops collecting and the customer is gone before anyone notices.

Standards and rails

  • ISO 8583
  • ISO 20022
  • ACH and NACHA rules
  • SEPA and SEPA Instant
  • FedNow and RTP
  • Card acquiring and processing
  • Payment facilitator and sub-merchant models
  • PSD2 and open banking

Rails work we have done

We built a payment facilitator for a US startup directly on Chase rails, carrying card acceptance, ACH, refunds, chargebacks and dispute management with no aggregator in the path.

It went from nothing to production in under twelve months, and JPMC called it one of the fastest payfac implementations they had seen.

The components around it covered processing, payouts over ACH, tokenization, KYC and sanctions screening, so no part of the flow waited on a provider roadmap.

At BVNK we built a distributed core banking platform: multi-currency accounts, generated account numbers and IBANs a bank can route to, over ISO 20022 and ISO 8583.

Related work: Ledger design and money movement. Card data, tokenization and PCI DSS scope.