Core banking software built for your operating model

The right core banking platform should fit the business you intend to operate—not force the business into a generic demo. Macrobank gives founders and technology leaders a configurable foundation that can support a greenfield launch, an extension into a new product or market, or the replacement of a legacy core. The scope is agreed around the customers you will serve, the accounts and currencies you will offer, the payment flows you must control, the providers you will connect and the operational evidence your team needs.

For a founder launching a regulated fintech, that means avoiding a multi-year internal build of ledger, accounting, permissions, payment orchestration and back-office infrastructure before the customer proposition can go live. For a CTO replacing a legacy platform, it means defining the future operating model first, mapping data and integrations, and selecting the ownership model that gives the organisation the right balance of control and delivery responsibility.

Macrobank is not a substitute for a licence, a sponsor bank, scheme membership, safeguarding arrangements, a card processor, a KYC decision or a compliance function. It is the software layer that records and controls the institution’s products and operations while integrating the external services allocated to those providers. If the requirement is only a consumer interface or a single payment connector, a full core may be more infrastructure than the project needs. If the business requires controlled accounts, balances, ledger entries, fees, payments and operational workflows, a core becomes central.

What Macrobank core banking software includes

Macrobank combines the stable operating core, the tools used by staff, customer-facing channels and provider integrations in one configurable platform. Exact scope depends on the delivery model and agreed project package. The distinction between base platform capability, optional modules and external services is important: it shows what Macrobank records and controls, what can be added, and what still depends on a bank, processor or specialist provider.

The operating core

The operating core holds the controlled customer, account, balance and transaction record. It supports customer and business profiles, account and IBAN structures, multi-currency products, transaction posting, payment and transfer workflows, foreign-exchange configuration, tariffs, fees and limits. Double-entry financial accounting and general-ledger functions provide the internal record needed for financial control, while reconciliation and reporting help operators compare that record with banks, payment providers and other external positions.

Product rules can be configured around the institution’s proposition. That includes account types, currencies, fee schedules, transaction restrictions, approval rules and user permissions. Configuration does not remove the need for product and compliance decisions; it turns those decisions into controlled system behaviour that can be tested, operated and audited.

Customer channels and back-office operations

Macrobank can include branded web and mobile channels for customers and a back-office environment for administrators and operators. Customer channels present the products and services supported by the core: onboarding journeys, account information, beneficiaries, transfers, statements and related actions. The back office supports the teams responsible for customer administration, transactions, exceptions, reporting, reconciliation and system configuration.

Roles and permissions should reflect who may view information, approve an action, release a payment, change a rule or investigate an exception. The channel never becomes an independent source of truth; it reads from and sends instructions to the controlled operating core.

Optional cards and crypto modules

The optional cards module supports the operational card lifecycle: physical or virtual card ordering, activation, block and unblock, closure, renewal and replacement, transaction and authorisation history, account funding movements, statements and reconciliation. Macrobank coordinates the customer and operator workflows and connects to the selected issuer and processor. The issuer, processor and card scheme still perform the regulated and technical functions allocated to them; Macrobank should not be described as a card processor or scheme member.

The optional crypto-fiat module can support wallet and account workflows, fiat and digital-asset views, transaction records and integrations with custody, blockchain and KYT providers. The precise custody model, asset support, transaction execution and compliance controls depend on the legal structure and selected external providers.

External services and integrations

Macrobank connects to the services that complete the operating model: banks and payment rails, card issuers and processors, KYC/KYB and screening services, FX and liquidity providers, messaging tools, data services and other specialist systems. Advapay maintains a broad catalogue of prebuilt integrations and can scope additional connections where the project requires them. Availability and fit must be confirmed against the current integration inventory, provider version, geography and contracted service.

The matrix describes technology scope, not regulatory sufficiency. Final modules, responsibilities and providers are confirmed during discovery and fit-gap analysis.

How Macrobank fits between your product and providers

Macrobank acts as the controlled operating and ledger layer between customer or operator channels and the external providers that deliver banking, payment, card, identity, FX or digital-asset services. This boundary prevents the customer app, a payment connector or an external provider status from becoming the institution’s only financial record.

A customer may open an account in a branded web or mobile interface. Macrobank applies the configured product, customer and permission rules, creates the corresponding records and coordinates required provider checks. When a payment is initiated, the platform validates the instruction, applies relevant fees or limits, sends the message through the selected bank or rail adapter, records the evolving status and preserves the internal postings needed for reconciliation.

The external provider remains responsible for the service it performs. A KYC service returns identity or screening results; the regulated institution remains responsible for its policy and acceptance decision. A bank or payment rail transports or settles the payment; Macrobank records, controls and reconciles the institution’s position. A card processor handles processing and scheme connectivity; Macrobank manages the account-side and operational lifecycle agreed in scope.

This layered model also clarifies the difference between core banking software and Banking-as-a-Service. Macrobank is software. BaaS supplies regulated or financial capabilities through a provider relationship. A fintech may use both, but the contract, permissions, infrastructure and risk ownership must remain explicit.

Choose SaaS, a software licence or source-code ownership

Macrobank can be delivered in three ways so the buyer can choose how much infrastructure, release and engineering responsibility to own. SaaS usually offers the fastest route for a standard scope because Advapay operates the platform service within the agreed contract. A perpetual licence gives the customer greater control of its environment while retaining vendor software and support. Source-code ownership adds the ability—and the responsibility—to maintain and change the platform independently.

Choose SaaS when time-to-market and a managed operating model matter more than direct infrastructure control. Choose a perpetual licence when the institution or its technology partner needs to operate the environment but does not want to rebuild the platform. Choose source code when independent engineering control is strategically necessary and the organisation is prepared to own security, release, merge, test, support and long-term maintenance responsibilities.

The best choice depends on the target jurisdiction, outsourcing approach, internal capability, customisation needs, exit requirements and economics over several years. Compare the models in the commercial SaaS and software-licence guide and the editorial SaaS vs licence vs source-code framework. Exact pricing is not published because environments, modules, integrations, migration and support materially change the scope.

Implementation, integrations and go-live

A Macrobank implementation is a configuration-and-integration programme with defined operational acceptance—not a software installation followed by an improvised launch. Advapay begins by clarifying the product, licence or regulatory route, customers, currencies, payment flows, providers, reporting needs, delivery model and existing systems. That creates a fit-gap view: what the standard platform already supports, what requires configuration, what needs an integration and what genuinely needs additional development.

1. Discovery and fit-gap

The project team translates the business proposition into testable platform requirements. This includes customer types, account products, currencies, fees, limits, approval rules, user roles, reports, reconciliation, provider messages and exception scenarios. For a replacement, discovery also covers the current data model, historical records, integrations, operational pain points and cutover constraints.

2. Configuration and integration

Advapay configures agreed products and workflows and connects the providers included in scope. A prebuilt adapter can reduce delivery effort, but the current provider API, credentials, test environment, commercial agreement and required message set still need validation. Custom connections are scoped against documented APIs, error handling, retries, status mapping, reconciliation and operational support.

3. Testing and operational readiness

Testing should cover happy paths and exceptions: customer acceptance or rejection, account changes, fees, limits, payments, reversals, duplicate messages, timeouts, provider failures, balance and ledger reconciliation, permissions, reports and audit history. The client’s product, operations, compliance, finance and technology owners confirm that the service behaves as intended and that staff know how to handle exceptions.

4. Migration, cutover and go-live

A greenfield project may have little historical data but still needs production provider access, operational procedures and readiness checks. A replacement requires mapping, cleansing, trial migrations, reconciliation, rollback planning and evidence that balances and critical history are preserved. A staged migration can reduce risk where products, customer groups or integrations can move separately.

For a standard settled scope, implementation can be planned over approximately two to three months after requirements and provider dependencies are agreed. That is a planning range, not a guarantee. Full card programmes, crypto, mobile applications, migration, multiple new integrations or complex acceptance commonly require six months or more. The client does not need high-end platform-engineering expertise for a standard delivery, but it must understand the business it is building, give clear guidance, make timely decisions and assign accountable product, operations, compliance and technical owners.

Security and operational controls

Security depends on the software, its configuration, the deployment environment, connected providers and the teams operating them. Macrobank supports role-based access, different permission levels, authentication controls, audit history and encrypted communications between components. Customer-facing authentication can support strong customer authentication flows where required by the product and applicable rules.

Operational control also means knowing who changed a rule, approved an action, released a payment, handled an exception or exported information. Roles should follow least-privilege principles and be reviewed as responsibilities change. Sensitive actions may require separation of duties or additional approval. Logs, reports and provider statuses should be monitored and reconciled rather than stored without an operating process.

Infrastructure responsibilities vary by delivery model. In SaaS, Advapay operates the contracted platform environment and release process. Under a customer-controlled licence or source-code model, the customer assumes more responsibility for hosting, access management, monitoring, backups, recovery, patching and deployment. External providers retain responsibility for their own services. During evaluation, buyers should request current evidence for the exact service and deployment in scope rather than rely on broad claims or unrelated certifications.

Integrate the providers your model requires

A usable core banking platform must connect to the financial and compliance infrastructure available to the business. Macrobank’s integration layer supports banks and payment rails, card issuers and processors, KYC/KYB and screening services, FX and liquidity providers, messaging tools and other specialist systems. Advapay maintains a catalogue of prebuilt integrations and can assess additional connections.

“Prebuilt” should not be treated as “zero work.” Provider APIs, authentication, message formats, webhooks, status codes, retry behaviour, reconciliation files and commercial access change over time. Each integration must be validated against the required geography, currencies, products and production service. A well-scoped integration includes error handling, monitoring and an operating owner—not only a successful test call.

When selecting providers, start with the target operating model and licence permissions. Then assess reach, settlement, safeguarding or sponsorship structure, onboarding requirements, service levels, data residency, pricing, reconciliation and support. This is where Advapay’s broader experience can help connect the software decision to banking access and payment infrastructure rather than treating integrations as an isolated technical list.

Macrobank in operation: European SecurePay Center and PayoNet

Why work with Advapay

Advapay can support the technology decision in the context of the regulated business that must operate on it. Macrobank is actively used by more than 50 payment service providers. The delivery team works with founders, product owners, operators and technology leaders on configuration, provider integrations, testing, migration and go-live—not only on software procurement.

For a new fintech, Advapay can also support licensing or registration work, compliance and operational preparation, banking access and provider coordination where those services are included in the engagement. For an established institution, the focus may be a platform replacement, a new delivery model, a product extension or the connection of additional providers. These services remain separately scoped; buying the software does not itself grant regulatory permissions or banking access.

The practical benefit is a joined-up implementation conversation. Product rules affect platform configuration. Licence permissions affect the services that can be offered. Providers affect payment reach and reconciliation. Operational procedures affect roles, reports and exceptions. Treating those decisions together reduces avoidable gaps between a technically working system and a service that the organisation is ready to operate.

Read the broader core banking software guide, review modern core banking architecture, or move directly to a tailored product demonstration.