Building a Compliance-Ready Tech Architecture for a Maltese Payment Institution

Most guidance on MFSA outsourcing and technology requirements is written for firms retrofitting compliance onto an existing platform. This is the opposite question: what does a payment institution’s architecture look like if compliance is designed in from the first decision, rather than reviewed in afterward.

Chapter 3 of the Financial Institutions Rulebook and the MFSA’s broader guidance on technology arrangements set out what a licensed payment institution must demonstrate — classification of critical functions, outsourcing governance, ICT risk management, safeguarding controls. A firm building its technology stack for the first time has a genuine advantage most established institutions don’t: the chance to build the architecture so these requirements are satisfied structurally, rather than bolted on as a compliance layer over decisions already made for other reasons.

Who this is for

• The founder or CTO building a Malta-licensed payment institution’s technology stack pre- or shortly post-authorisation.
• The board reviewing whether an early-stage technology build is being sequenced with regulatory readiness in mind, not just product speed.

Start with classification, not with vendor selection

The MFSA’s own thematic review findings show critical and important functions repeatedly misclassified as non-critical — Compliance, Risk, and Internal Audit functions, specifically, have been flagged as commonly under-classified. For a firm building from scratch, the sequencing matters: decide and document which functions are critical or important against the regulatory criteria before selecting vendors for those functions, not after. A vendor selected first, and reclassified as critical only once the relationship is already live, tends to lack the contractual protections — audit rights, exit provisions, sub-outsourcing controls — the classification should have required from day one.

Design the register before the first vendor contract, not after the tenth

The MFSA reads the outsourcing register as a dependency map — sub-outsourcing chains, data processing locations, substitutability, exit strategy — not an administrative vendor list. A firm building its stack from zero should design the register’s structure before signing the first material contract, so every vendor decision populates it consistently from the outset. Retrofitting this structure onto ten or fifteen live vendor relationships, each documented differently, is a materially bigger undertaking than building it into procurement from the start.

Intra-group arrangements need the same rigour from day one

A common pattern for a new Maltese payment institution backed by an international group: core technology genuinely does sit with a parent or affiliate, for entirely legitimate reasons of cost and expertise concentration. The MFSA has been explicit that intra-group outsourcing carries the same risks as third-party arrangements and must be held to the same standard — risk assessment, contractual terms, ongoing oversight. Building the architecture with this in mind from the outset means the intra-group technology relationship is documented and governed to outsourcing-register standard immediately, rather than treated informally because “it’s just group IT” until an inspection specifically asks about it.

Sub-outsourcing visibility as an architecture requirement, not a contract clause

The MFSA expects visibility into sub-outsourcing chains — where a primary vendor’s own vendors sit, and what data or processing they touch. This is achievable as a contractual requirement, but it’s considerably more reliable when the architecture itself is designed to make sub-processor dependencies visible — API-level integration documentation that records which downstream services a given vendor actually calls, rather than relying entirely on the vendor’s own disclosure. A firm building its integration layer with this documentation discipline from the start avoids discovering, mid-audit, that a core vendor quietly routes a specific function through an unassessed sub-processor.

Safeguarding architecture: build the segregation in, don’t graft it on

Client fund safeguarding — segregation, reconciliation, audit obligations — is one of the areas MFSA thematic reviews have flagged most consistently, including concentration in a single safeguarding channel and inadequate assessment of safeguarding methods. For a firm building from zero, the ledger and reconciliation architecture should treat safeguarded funds as structurally distinct from operational funds at the data model level, not as an accounting convention applied after the fact on top of a single unified ledger. This is a meaningfully cheaper decision to make at the design stage than to retrofit once transaction volume has grown.

What a compliance-ready build actually looks like

1. A documented critical-function classification completed before vendor selection for those functions, not after.
2. An outsourcing register structure designed before the first material contract, populated consistently from vendor one.
3. Intra-group technology arrangements documented and governed to the same standard as third-party ones, from the first agreement.
4. Integration architecture that records downstream sub-processor dependencies at the technical level, not just the contractual one.
5. A ledger and reconciliation design that structurally segregates safeguarded funds, rather than layering segregation on afterward.

How we engage with this

We review early-stage technology architecture against what MFSA will actually expect to see at inspection — before the vendor relationships and data model decisions are locked in — as an Architecture Review. The output is a written assessment identifying which design decisions should be made now, while they’re still cheap to change.

We don’t build the platform. We don’t select vendors on a client’s behalf. We don’t represent firms to the MFSA. We read what’s planned, identify what’s missing, and write it down for the people who have to decide what to do about it.

Pricing is published at /pricing/. If you’re building a Maltese payment institution’s technology stack from the ground up, the place to start is a conversation.

Sixteen Pillars is a technology governance consultancy based in Cyprus. Engagements run remote across the EU, UK, and Middle East, with on-site time where the engagement requires it.