Practitioner notes. Opinionated framings of the terms our advisors use most often.

Pre-approval is an informal positive indication from a banking partner that they would accept the applicant before any formal application is lodged. It is the central artefact in finconduit's banking-introduction methodology, and it is fundamentally different from the retail-banking concept of "pre-approval" used in consumer credit underwriting. Where retail pre-approval is automated scoring against published criteria, institutional pre-approval is a human compliance review of a structured pack against the receiving bank's internal risk-appetite rules — many of which are not published anywhere.

The pre-approval is obtained through pre-positioned relationships. The practice has prior conversations with each banking partner's compliance team about the categories of regulated entity they will and will not accept, the documentation standards they apply, and the substance requirements they expect. When a client engages, the matching exercise picks the partners whose published and unpublished criteria align with the client's profile. A category brief — not the full application — is then submitted for the partner's compliance team to review.

Two metrics validate that the methodology works rather than acting as a polite filter that the formal stage would have caught anyway. The first is the pre-approval success rate (87% across the engaged client base), measuring how often pre-positioned introductions result in a positive informal indication. The second is the formal rejection rate post pre-approval (under 8%), measuring how often pre-approved applications nonetheless fail at the formal stage. The pair shows that the pre-approval is doing real work: it accepts most applications it sees, and the ones it accepts almost always succeed.

A pre-approval is not a guarantee. Formal rejections still happen, usually because new information surfaced during formal due diligence — a director's prior insolvency, a UBO change made between pre-approval and submission, or a material funds-flow shift. The pre-approval simply ensures the formal application is going to a partner positively disposed to accept it.

De-risking is always a process the bank initiates, never a state the client is in. The framing matters because the language people often reach for — "high-risk client", "high-risk sector", "the company was deemed high-risk" — centres the client when the actual cause is the bank's risk-appetite limitation. A regulated EMI in Lithuania does not become "high-risk" between Tuesday and Wednesday; what changes is the bank's internal policy or its correspondent banking pressure or its supervisory examination findings.

Default verb: de-risk (active, the bank is the subject). Default noun: de-banking (the event the client experiences). Active voice on the bank's side puts accountability where it belongs and prevents the client framing from leaking into compliance documentation, where it can later be cited against the client by the next bank reading the file.

In practice, three causes account for almost all de-risking events. The first is correspondent banking pressure: a respondent bank's USD-clearing correspondent gets cautious about the respondent's client base and pushes restrictions downwards. The respondent bank then cuts loose the marginal clients whose volume does not justify the correspondent friction. The second cause is supervisory pressure: an NCA examination identifies the bank as carrying disproportionate exposure to a sector and the bank reduces that exposure to clear the finding. The third is internal policy drift: a change of CRO or board-level risk appetite resets the threshold for what counts as acceptable.

None of those causes is about the specific client. The client typically only sees the account closure email, written in standard language, and is told that the relationship is ending without specific reason. From the client's perspective the experience is opaque, sudden, and personal. From the bank's perspective it is impersonal portfolio management. The advisory work is reconstructing the actual cause from the patterns and presenting the next bank with documentation that addresses it.

finconduit's tiering of banking partners is by willingness and process, not by balance-sheet size. The conventional bank tiers used in capital adequacy or systemic-risk discussions do not predict whether a particular bank will onboard a particular fintech, so the practice uses a different categorisation when scoping a banking introduction.

Tier-1 in the practice's usage refers to the major retail and commercial banks with formal, documented de-risking policies on regulated fintech sectors. These banks have well-staffed compliance functions, sector-specific exclusion lists, and slow application processes that involve multiple committees. The bar for acceptance is high; when a Tier-1 partner does say yes, the relationship is unusually robust because the institutional process forces a thorough review. Tier-1 yeses are rare for crypto-adjacent businesses but happen for clean EMI and PI applicants with substantive operations.

Tier-2 partners are specialist banks that have built a defined process for fintech onboarding. They are not the major commercial banks, but they have made the strategic decision to serve the regulated-fintech sector and have invested in compliance staff who understand it. Their bar is high but proportionate, and their timelines are measurably shorter — typically four to eight weeks from formal application versus the three-to-six months at Tier-1. Tier-2 is where most successful banking introductions for fintechs actually land.

Tier-3 covers crypto-native and challenger banks. These institutions have built their entire compliance infrastructure around the digital-asset and fintech sector. They onboard fastest, and for many VASPs and CASPs in the early years of MiCA they are the only realistic banking partner. Their commercial terms are more expensive and their balance sheets are smaller, so they are usually a starting point for a multi-bank architecture rather than the destination. The right answer for most institutional clients is a combination across tiers — Tier-3 for operational accounts in the first year, Tier-2 for the safeguarding bank, with the longer-term strategy of upgrading to Tier-2 or Tier-1 once the engagement track record supports it.

Banking partner risk appetite is the hidden variable that explains the majority of banking outcomes in regulated fintech. Two CASPs holding identical MiCA authorisations from the same NCA, with equivalent capital, equivalent management, and equivalent activity profiles, can have wildly different banking-access results. The difference is not their licence type, their AML programme, or even their lawyers. It is which banking partners they were matched with and how the application was framed for those specific partners.

This is why generic banking-introduction services produce inconsistent outcomes. The introduction itself — the act of putting an application in front of a banker — is not the work. The matching is the work. A correctly matched application from a Cypriot Investment Firm can succeed where an incorrectly matched application from a German EMI fails, even though the EMI looks objectively stronger on paper. The CySEC-licensed firm wins because the partner it was introduced to had a clear positive disposition toward CIFs in that activity range. The German EMI loses because it landed in front of a partner whose policy was tightening on EMIs that month.

Risk appetite is also dynamic. A banking partner that was open to VASPs in 2024 may close that intake in mid-2025 after a supervisory examination, then reopen in late 2026 with revised criteria. The advisory work is keeping current on which partners are open, what criteria they are applying right now, and how they want applications presented this quarter. That is not information that publishes itself; it comes from the practitioner relationships that the advisory firm maintains and from the running record of recent outcomes.

The implication is that the licence-selection decision and the bank-selection decision are intertwined. A client who is choosing a jurisdiction without simultaneously evaluating which banking partners will actually accept that jurisdiction's licence is solving the problem in the wrong order. The right sequence is to identify three to five banking partners that fit the client's profile, confirm the partners' current intake criteria, and then choose a licence jurisdiction that those partners accept.

The pre-approval pack is the deliverable prepared for a banking introduction. It is not the application form. The application form goes in later, at formal stage, and it is typically the bank's own template. The pre-approval pack is the practitioner-built artefact that gets a positive informal indication out of the receiving bank before the formal stage begins.

The contents are deliberate. An AML policy executive summary, distilled to five-to-ten pages from the eighty-page full document, captures the operational reality of how money laundering risk is managed without burying the reader in policy language. The sanctions-screening framework states which lists are screened, against what frequency, with which technology stack. The transaction-monitoring rule set lists the actual scenarios and thresholds that fire alerts, not the abstract statement that monitoring exists. The MLRO bio includes the regulator-register reference (FCA Register link, EBA register reference, equivalent NCA register) so the reviewing bank's compliance officer can verify the appointment in thirty seconds. A funds-flow diagram shows where money enters and exits the system in plain visual form. A source-of-funds attestation explains how the client's own capital was raised and how the operating funds will be replenished.

The pack is assembled in the format the receiving bank's compliance team actually wants to read, which is meaningfully different from what the regulator's authorisation file requires. The regulator wants exhaustive; the bank wants legible. The regulator reads in detail across hundreds of pages; the bank's compliance officer is reviewing sixty applications a week and gives the pack twenty minutes on first pass. Documentation prepared for one audience and submitted to the other underperforms even when the substance is identical.

A pre-approval pack also varies per banking partner. The same client engagement produces different packs for different partners because each partner's compliance review template, document preferences, and risk-language conventions are different. That partner-specific tailoring is part of what generates the pre-approval rate finconduit tracks. A pack that lands at a generic bank is statistically less likely to convert than a pack that lands at the bank it was specifically built for.

Correspondent banking pressure is the hidden cause of much de-risking, and the constraint that explains most account closures whose stated reason does not match the actual reason. Correspondent banks — typically the major USD-clearing institutions that respondent banks rely on for international settlement — push de-risking decisions downwards through the chain. When a correspondent gets cautious about its respondent's client base, the respondent has two choices: lose the correspondent relationship, which is existential, or restrict the relevant clients, which is merely commercially painful.

The de-banked client almost never sees the correspondent. From the client's perspective, the experience is that their bank — the bank they have a contract with, the bank whose name appears on their account statements — sent them a closure notice. They direct their analysis at that bank. They write to the bank's CEO. They consider escalation to the local NCA. None of that touches the actual constraint, because the local bank was not the constraining party. The local bank was responding to a constraint imposed two layers upstream, by an institution the client has never had any direct contact with.

This is also why "shopping for a different bank in the same country" often does not work. If the constraint is correspondent-pressure-driven and most banks in that country use the same correspondent, the next bank will eventually face the same pressure. The strategically sound response is to change the correspondent geography of the banking architecture: identify banks in jurisdictions whose USD-clearing arrangements run through different correspondents, or whose business is largely euro-denominated and therefore correspondent-light.

In casework, the practice confirms a correspondent-pressure pattern when several seemingly unrelated banks decline a profile within a short window. The correlation is the signal. One refusal is a portfolio decision. Five refusals across five different banks in three months, all citing different surface-level reasons but converging on the same client profile, points at a correspondent-level constraint. The advisory work is mapping the correspondent geography and routing the client into a banking architecture whose dollar exposure runs through correspondents not affected by the original pressure.

Substance is the regulatory expectation that a licensed entity has real local presence in the jurisdiction that authorises it: directors physically resident in the jurisdiction, real employees on the ground, a real office, real decision-making conducted locally. Not just a registered address, not "fly-in" directors who attend board meetings quarterly and live elsewhere, not nominee directors with no operational involvement. Substance is the question that NCAs ask increasingly aggressively as they review whether a licensed entity is genuinely doing in their jurisdiction what its licence permits.

NCAs apply substance differently. Bank of Lithuania has been particularly demanding since 2023, and several Lithuanian-licensed EMIs that had thin substance have either had their licences withdrawn or been required to migrate operations to Vilnius within compressed timelines. Cyprus has historically been more relaxed but has tightened materially since the FATF mutual evaluation. Malta similarly tightened post the same review cycle. The general direction across the EEA is for substance requirements to harden, not soften.

In structuring exercises, substance should be budgeted from day one of the planning, not retrofitted after the licence is granted. Retrofit substance is expensive — a sudden need for resident directors at six-figure annual cost, a sudden need to relocate operational staff, a sudden need to lease an office that fits the description previously given to the NCA. Pre-planned substance is much cheaper because hiring and leasing decisions are made on normal commercial terms rather than under regulatory deadline pressure.

The substance test is also forward-looking. NCAs do not just ask whether substance was present at the moment of licensing; they ask whether it has been maintained as the business has scaled. A licensed entity that grew its volume tenfold without proportionately scaling local staff, or whose senior decision-makers gradually relocated abroad over a two-year period, may pass a substance review at year zero but fail one at year three. The advisory work includes ongoing substance monitoring and explicit board-level review of the substance posture as the business changes.

Reverse solicitation is often misframed as a "loophole" letting offshore firms serve EEA customers without an EEA licence. It is in reality a narrow exemption that applies only when the customer initiated contact themselves, unambiguously, and the firm has done no marketing into the EEA. The exemption is real and useful, but the bar for relying on it is much higher than most operators assume, and ESMA along with the NCAs have been progressively tightening their interpretation of what "no marketing" actually means.

Things that compromise reverse solicitation status: paid advertising targeting EEA users, EEA-language customer support, app-store storefronts that target EEA storefronts (even by default, where the firm did not actively localise), affiliate-referral programmes with EEA-domiciled affiliates, EU-targeted SEO content (even where the firm did not directly intend EEA traffic), webinars open to EEA participants, conference attendance and exhibition stands inside the EEA, and direct sales outreach into the EEA. Any one of those pulls the firm into MiCA scope regardless of where the entity is incorporated.

The "no marketing" test is also continuous. A firm that did not market into the EEA when an account was opened, but began doing so two years later, loses reverse solicitation cover for new EEA customers from that point and arguably for the existing book as well. The exemption is not banked at the moment of customer onboarding; it has to remain true throughout the relationship.

In practice, reverse solicitation should not be relied on as a market-access strategy. It works as a defensive position — protection against incidental EEA customers who genuinely found the firm without prompting — but it is not a substitute for a CASP authorisation when the firm wants to grow EEA volume. Operators that build their EEA strategy on the exemption tend to compromise it through normal commercial activity within twelve to eighteen months and end up needing the licence anyway, often under time pressure that produces a worse outcome than an early authorisation pursued from a position of stability.

Article 143(3) MiCA provides a transitional period for entities authorised under national frameworks before 30 December 2024. Most EEA member states' deadline is 1 July 2026, by which date pre-MiCA authorised CASP-equivalent entities must hold a full MiCA authorisation or cease the relevant activity. Some member states shortened the period to eighteen months from MiCA's date of application, which puts their cliff in mid-2026 rather than at the default 1 July 2026 date. The cliff is not uniform across the EEA, and operators with multi-jurisdictional footprints need to track each member state's specific deadline.

The grandfathering provision is widely misunderstood as an exemption from substantive MiCA requirements during the transitional period. It is not. Grandfathered entities are required to comply with MiCA's substantive obligations (capital, governance, custody, AML, white-paper disclosures where relevant) from MiCA's date of application; the grandfathering only suspends the formal authorisation deadline. An entity operating under grandfathering that is non-compliant with MiCA substance does not gain a defence by invoking the transitional period.

The practical risk is supervisory processing time. Grandfathered entities that submit a complete authorisation file in 2025 are more likely to be processed before the cliff than those submitting in early 2026. Several NCAs are openly signalling that applications submitted late in the transitional period may not be reviewed in time, with the consequence that the entity loses its ability to provide the relevant CASP services on the cliff date even though it has an application pending. The conservative planning horizon is to file a complete and review-ready authorisation file no later than autumn 2025, accepting some inefficiency on the timing in exchange for certainty that the application will be processed before the cliff.

Operators relying on grandfathering should also keep continuous communication with their NCA. NCAs are explicitly more accommodating to applicants that have engaged early and kept their progress visible than they are to applicants that surface only when the deadline approaches.

Programme of Operations is the required document at the centre of every EU and UK financial-services authorisation application. It is not a marketing brochure, not a pitch deck, and not a summary of the business plan. It is a structured walkthrough of services offered, target customer base, AML framework, governance structure, ICT setup, third-party dependencies, capital adequacy, and operational continuity. NCAs use it as the spine of their review — every other document in the file is read against the Programme of Operations, and inconsistencies between the Programme and the supporting documentation are routinely flagged in RFIs.

NCAs reject authorisation applications more often for thin Programme of Operations than for missing capital. Capital is binary: it is there or it is not. A Programme of Operations is a quality artefact, and quality varies along a continuous scale. Reviewers can identify a document that has been put together by someone who understands the business and the regulation, versus one that has been adapted from a template without genuine engagement with the operations. The former gets through; the latter generates a compounding sequence of RFIs that often cause the application to stall.

A serious Programme of Operations runs to forty to eighty pages of operational specificity. It describes how customer onboarding actually flows, naming the systems and the human approval points. It describes how transactions are monitored, naming the rule scenarios. It describes how the management body actually meets, what it discusses, and how it documents decisions. It describes the failure modes the business has thought about and how it responds to them. It describes the third-party providers, what they do, and how the entity supervises them.

The most common failure pattern is a Programme of Operations that reads like a description of an aspirational future state rather than an operational present. NCAs want to know what is happening today, not what will happen once the licence is granted. An applicant that cannot describe its present operations in concrete detail is signalling that the operations do not yet exist, which means substance, governance, and ICT readiness are likely also gaps. The Programme of Operations is the document where these gaps surface earliest.

Fitness and propriety is the regulatory test applied to senior individuals in financial-services firms, both at authorisation and on an ongoing basis throughout the firm's life. Article 68 MiCA is the current EEA touchstone for CASPs; equivalent provisions apply under EMD2 and PSD2 for EMIs and PIs, and the FCA's Senior Managers and Certification Regime (SMCR) operates under similar principles in the UK. The test assesses each member of the management body and other key persons on knowledge, skills, experience, reputation, honesty, integrity, and (depending on the regime) financial soundness.

Reputational issues have been the rejection point for a meaningful share of late-stage authorisation applications. The technical components — knowledge, skills, experience — are usually documented in advance through CVs, qualifications, and prior employment. The reputational component is researched by the NCA itself: Companies House searches, sanctions-list screens, regulatory references from prior employers, adverse-media checks, criminal-record requests, and (increasingly) reviews of public statements made by the individual including social-media activity. NCAs maintain memory across applications, and an individual whose name has appeared in a previous regulatory issue will be flagged.

In practice, the fitness-and-propriety review is two-stage. The first stage is documentary: the applicant provides the certificates, references, and declarations. The second stage is the NCA's own corroboration: they cross-check what was declared against what their own searches turn up, and gaps or inconsistencies become immediate RFIs. A single undeclared prior directorship of a struck-off company, even if commercially innocuous, often produces enough doubt to slow a review by months.

The implication for management-body composition is that reputational due diligence on the candidate pool needs to happen before names go into the application, not after the NCA flags a problem. The advisory work includes screening senior candidates against the same checks the NCA will run, identifying potential issues, and either remediating them (where remediation is possible) or substituting candidates (where it is not). The substitution conversation is uncomfortable but is much cheaper to have at the structuring stage than after a six-month delay caused by the NCA discovering something the applicant did not disclose.

Pre-application engagement is the informal pre-submission meeting offered by some NCAs where a prospective applicant can preview the proposed business model and receive feedback before formally lodging the authorisation file. Bank of Lithuania has been particularly active in offering these engagements; Cyprus, Malta, and the Central Bank of Ireland offer them on a more selective basis depending on the applicant's profile and the supervisory unit's current workload. France and Germany have more formal regulatory-dialogue mechanisms that achieve a similar function with more procedure attached.

Where pre-application engagement is available, it is one of the strongest signals about an NCA's intent to authorise good firms quickly. NCAs that invest staff time in informal pre-submission meetings are demonstrating that they want the application to succeed and that they prefer to surface concerns early when they are fixable rather than after formal submission when they generate an RFI cycle. The economic logic for the regulator is the same as for the applicant: it is cheaper to talk for an hour pre-submission than to handle a multi-RFI back-and-forth that consumes weeks of staff time.

For the applicant, pre-application engagement materially de-risks the formal review. Concerns the NCA raises in the meeting can be addressed in the application itself rather than in a corrective response after submission. The applicant also gets a sense of the NCA's current priorities — substance, ICT risk, AML, governance, custody — which lets the application emphasise the right material. And the applicant builds a relationship with the supervisory team that handles the file, which has knock-on benefits during ongoing supervision after the licence is granted.

When a prospective applicant is choosing between jurisdictions for an authorisation strategy, the availability and quality of pre-application engagement is a meaningful selection criterion. A jurisdiction that offers a substantive pre-meeting and uses the time well is signalling something positive about how it will handle the substantive review. A jurisdiction that does not offer the meeting, or offers a fifteen-minute formality, is signalling something different. Other things equal, the practice routes new applications through jurisdictions where pre-application engagement is real.

In-principle approval is a non-binding indication from a regulator that they are prepared to grant an authorisation subject to specified conditions being met. The mechanism is most established in MAS (Monetary Authority of Singapore) and HKMA (Hong Kong Monetary Authority), where IPAs are a standard step in the licensing pathway for payment institutions and crypto-asset service providers. IPA-equivalent processes are emerging across EEA NCAs but are not yet uniformly available; some member states have informal versions, others have not adopted the concept at all.

The conditions attached to an IPA are typically operational rather than commercial. Capital must be deposited and held in the form specified. Specific senior hires named in the application must be in post and physically resident in the jurisdiction. Defined IT systems must be operational and tested. Office space must be secured and staffed. The regulator gives the applicant a window — commonly six to twelve months — to fulfil the conditions, and grants the formal licence once the applicant evidences fulfilment.

IPA is conceptually distinct from banking pre-approval. Both are conditional, but the issuing party and the substance are different. An IPA is issued by a regulator and conditions the formal grant of an operating licence; a banking pre-approval is issued by a banking partner and conditions the offering of a commercial banking relationship. They sit in different points of the structuring sequence: IPA before licence issuance, banking pre-approval typically after licence issuance and before commercial launch.

Operationally, IPA is valuable to applicants because it allows them to make capital-deployment and hiring decisions with confidence. Without IPA, an applicant pursuing a licence faces a binary risk: spend on substance and pre-licensing operations, then either receive the licence (and the spend was good investment) or not (and the spend was loss). With IPA, the binary collapses: the spend is deployed against a regulator-confirmed pathway to the licence, and the conditional outcome shifts the risk profile materially. Jurisdictions that offer well-functioning IPA processes therefore attract applicants whose capital is more carefully managed and whose substance is more genuinely scaled — which compounds positively for the jurisdiction's regulatory reputation.

MiCA passporting is the mechanism in Article 65 MiCA under which a CASP authorised in any EEA member state can provide its authorised services across all 30 EEA member states by giving notice to ESMA and to the host-state NCAs. The passporting regime is structurally what makes a Lithuanian, Maltese, Cypriot, German, or Irish CASP authorisation strategically equivalent for an operator with pan-EEA ambitions: pick the jurisdiction whose authorisation process best fits the firm's profile, and the resulting licence covers the entire single market.

The passporting concept is borrowed from PSD2 (which has long allowed EMIs and PIs to passport across the EEA) and from MiFID II (which does the equivalent for investment firms). Pre-MiCA, every EEA member state operated its own VASP regime, and a CASP-equivalent operator wanting to serve multiple member states had to register or authorise separately in each. That fragmentation produced expensive, repetitive compliance work and an arbitrage between member states whose VASP regimes were lighter. MiCA's passport closes that arbitrage and creates a single competition between NCAs on processing time, predictability, and supervisory quality rather than on regulatory permissiveness.

In practice, jurisdiction selection under MiCA is driven by four factors: NCA processing time (Bank of Lithuania has been fastest historically; Cyprus and Malta have been competitive; some larger member states are slower), substance burden (lower in some jurisdictions, materially higher in others), language and operational geography (English-speaking supervision is materially easier for non-local applicants), and pre-application engagement availability (a meaningful differentiator). The passport then takes the resulting licence into the rest of the EEA without re-authorisation.

Passporting is not unconditional. The host-state NCA can apply consumer-protection requirements that go beyond the home-state's, and any cross-border activity that includes a fixed establishment (an office, a branch) in the host state requires a freedom-of-establishment notification rather than the lighter freedom-of-services notification. CASPs operating across the EEA need to track which member states they are touching under which mode and ensure the corresponding notifications are in place. The mechanics are administrative but they are not optional, and ESMA has been clear that it expects CASPs to maintain accurate notification status.

An authorisation file is the complete regulatory submission for a financial-services licence application. It is meaningfully bigger than the application form alone, and the form is the smallest part of the work. A serious authorisation file for a MiCA CASP authorisation typically runs to two-hundred-plus pages, and that figure is comparable for an EMI or PI authorisation under EMD2 and PSD2.

The components of a complete file are well-defined. The Programme of Operations (forty to eighty pages of operational specificity, structured around the regulator's template). The AML policy suite (the full AML/CTF policy, customer-due-diligence procedures, transaction-monitoring rule book, sanctions-screening procedures, training records and curriculum). The ICT risk framework (since DORA, this is a substantial document covering ICT risk management, third-party ICT risk, incident reporting, and operational-resilience testing). Fitness-and-propriety attestations for each member of the management body and certified persons (CVs, references, criminal records, declarations). A capital-adequacy report demonstrating that the prudential floor is met under each calculation method. Governance documentation (board composition, committee structure, terms of reference, conflicts-of-interest policies). A third-party risk register listing every material outsourcing arrangement and the supervisory controls applied. A business continuity plan with explicit incident-response runbooks. Where relevant, a crypto-asset white paper or stablecoin-issuance prospectus.

NCAs read the file in detail. The conventional wisdom that "regulators only read the executive summary" is not true for authorisation reviews. The review team will run an evidentiary cross-check between the Programme of Operations and the supporting documents, look for inconsistencies, and turn each inconsistency into an RFI. Thin files generate extensive RFIs that delay the application by weeks-to-months per cycle. Files with internal inconsistencies — an AML policy that names a vendor not listed in the third-party register, a Programme of Operations that references a system not described in the ICT framework, a capital-adequacy report that uses a method inconsistent with the financial projections — generate RFIs at the most expensive rate.

The practical implication is that authorisation-file preparation is a coordination exercise. It is not enough for each component to be individually good; they have to be internally consistent and present a single coherent picture of the regulated entity. That coordination is the hardest part of the work, and is where applicants without specialist support most often struggle.

Multi-bank architecture is the modern fintech treasury pattern that explicitly diversifies banking relationships rather than relying on a single banking partner. The design principle is that no operating fintech should be one decision away from being unable to make payroll, settle a regulator, or refund a customer. A single banking relationship — even with a Tier-1 bank — can end with a thirty-day closure notice for reasons that have nothing to do with the fintech's own conduct.

In its strongest form, the architecture distributes liquidity across two or three banking partners with explicit segregation of function. Safeguarded client funds (held under PSD2 Article 10 or the FCA equivalent) sit on one bank that is dedicated to that function and that does not also handle operational money. Operational funds — payroll, vendor payments, day-to-day liquidity — sit on a second bank optimised for transaction throughput. Treasury reserve — capital held against prudential requirements, plus surplus operating cash — sits on a third bank, possibly in a different currency or correspondent geography. Each bank knows its role; each role has a designated primary and a documented fallback.

For EMIs specifically, the safeguarding bank should be different from the operating bank wherever possible. PSD2 Article 10 separation is a statutory minimum, not the ceiling of best practice. An EMI whose safeguarding and operating accounts are at the same bank has accepted concentration risk that a regulator would prefer it not have. EMI supervisors increasingly ask about the safeguarding architecture in detail, and a multi-bank pattern is a positive signal.

The architecture also has a banking-relationship management consequence. A fintech with three active banking relationships maintains negotiating leverage that a single-bank fintech does not have. The single-bank fintech is effectively held to whatever terms the bank offers; the three-bank fintech can route flow toward better-priced partners and away from worse-priced ones. Pricing on cross-border SWIFT, correspondent fees, and FX margins is meaningfully better for fintechs that demonstrate they are not captive.

The cost is operational complexity: three banks to onboard, three sets of compliance reviews, three lots of ongoing periodic-review documentation. That cost is real, but is materially smaller than the cost of being de-banked from a single relationship and trying to rebuild banking under time pressure.

Travel Rule threshold refers to the value above which originator and beneficiary information must travel with a transaction. The obligation derives from FATF Recommendation 16, originally written for traditional wire transfers and extended to virtual asset service providers in the FATF's 2019 Updated Guidance. The thresholds vary by jurisdiction: the EU sets €1,000, the UK £1,000, the US $3,000 under the FinCEN Travel Rule, Switzerland CHF 1,000, Singapore SGD 1,500, Hong Kong HKD 8,000. Operators with multi-jurisdictional exposure need to apply the most restrictive threshold relevant to each customer or accept the operational complexity of per-jurisdiction rule sets.

Below the threshold, simplified information is required (typically just sender and receiver name and account identifier). At and above the threshold, the obligation is much heavier: full identifying information for both the originator and the beneficiary (legal name, account number or wallet address, physical address or unique identifier such as date of birth or registration number) must travel with the transaction in a manner that the receiving VASP can verify and act upon.

In compliance teams, the most commonly missed point is that the obligation sits on the VASP/CASP, not on the bank. A traditional wire transfer between two banks is governed by the bank-side Travel Rule mechanics (SWIFT MT103 fields, ISO 20022 equivalents). A crypto-asset transfer between two VASPs or between a VASP and a self-hosted wallet is governed by the VASP-side mechanics, which require a separate technical layer entirely. The bank never sees the obligation; the VASP has to handle it.

Travel Rule providers (Notabene, Sumsub, Sygna, Veriscope, OpenVASP) handle the data plumbing. They route the originator-and-beneficiary information from the sending VASP to the receiving VASP via secure channels, verify counterparty identities, and produce the audit trail. The technical implementation is well-developed; the policy framing is what determines whether the implementation actually meets the spirit of the rule. A VASP that has bought a Travel Rule provider and switched it on has solved a third of the problem; the remainder is the policy framework that decides which transactions trigger which obligations, what counterparty due-diligence is applied to receiving VASPs, and how sub-threshold-but-related transactions are handled.

Self-hosted wallets are an ongoing complexity. The Travel Rule was designed for VASP-to-VASP transactions; transactions to or from self-hosted wallets do not have a counterparty VASP to exchange information with. Most jurisdictions require the VASP to obtain the same information from its own customer in respect of the self-hosted counterparty, which the customer may not actually know. The advisory work on Travel Rule policy framing therefore includes a clear position on self-hosted wallet handling.

KYT — Know Your Transaction — is the blockchain-analytics-driven monitoring layer that sits on top of conventional rule-based transaction monitoring. It is specific to digital-asset flows and addresses risk dimensions that conventional transaction monitoring cannot see. Source-of-funds attribution via on-chain analysis traces the history of crypto-asset flows back through the chain to identify whether incoming funds derive from sanctioned addresses, mixers, darknet markets, theft, or other categories of high-risk origin. Mixer and tumbler detection identifies funds that have passed through obfuscation services, which itself is a flag even where the ultimate origin is not directly linkable. Sanctions screening applies the same OFAC, EU, UN, and UK OFSI lists to wallet addresses as conventional sanctions screening applies to natural persons and legal entities.

KYT is distinct from KYC, which is identity-driven and applies at customer onboarding. KYC asks "who is this customer?" and verifies the answer through identity documents and biometric checks. KYT asks "where did this transaction's funds come from, and where are they going?" and verifies the answer through chain analysis. A regulated VASP needs both: KYC at onboarding to know who the customer is, KYT continuously to know what the customer is moving through the system.

KYT is also distinct from generic transaction monitoring, which is rule-driven and looks at internal transaction patterns (smurfing, structuring, rapid movement, deposits-followed-by-immediate-withdrawal). Generic transaction monitoring sees the customer's behaviour inside the VASP; KYT sees the customer's behaviour on the broader blockchain. A customer whose internal pattern is benign — small steady transactions, no rapid movement — may nonetheless be receiving funds from sanctioned addresses, and only KYT will surface that.

Vendor selection matters. The two market leaders for KYT are Chainalysis and Elliptic, with TRM Labs as a substantial third entrant and a longer tail of specialists. Each vendor's database covers different chains with different completeness, and different vendors have different attribution methodologies and different latency in tagging new addresses. For a CASP serving multiple chains (Bitcoin, Ethereum, Solana, Tron, the various L2s), single-vendor coverage may have gaps that show up only when a regulator examines a specific transaction set. Some compliance teams therefore deploy two vendors in parallel for redundancy; others accept the single-vendor risk in exchange for operational simplicity.

Compliance presentation layer is the practitioner term for the documentation kit prepared per banking partner — not just translating the AML policy, but repackaging it so it lands with the receiving bank's compliance team. Every regulated fintech has roughly the same underlying compliance content: an AML policy, a KYC procedure, a transaction-monitoring framework, a sanctions-screening setup, a governance structure, an MLRO appointment. The substance is similar across firms in the same regulatory category. What varies is how the documentation is assembled and presented to the receiving bank.

Different banks have different review checklists, different preferred document structures, different language conventions, and different concerns. A Lithuanian bank running a fintech-onboarding programme has a defined template that asks for the AML policy under specific section headings; a German bank running a different programme asks for the same content under different headings; a Cyprus bank has its own template again. The same underlying AML policy can be accepted at one bank and rejected at another based purely on how the content is assembled relative to the receiving bank's expectations.

The presentation layer is also a translation exercise from regulator-language to bank-language. A regulator-facing AML policy uses regulatory-statute language: "The institution shall apply enhanced due diligence in the circumstances set out in Article X of Directive Y." A bank-facing version of the same policy says: "Customers in the following categories require enhanced review by a senior compliance officer before onboarding: politically exposed persons, customers from FATF high-risk jurisdictions, customers whose business involves the categories listed in Annex A." The technical content is identical; the framing makes the second version legible to a banker reviewing sixty applications a week, and the first version legible to a regulator reading the file as part of a formal authorisation review.

In casework, the practice maintains a per-banking-partner template library. New documentation produced for a client is assembled into the template that fits the partner the client is being introduced to. The base content is the client's; the framing is the partner's. The investment in maintaining the template library is what makes the per-partner re-presentation efficient enough to apply consistently across engagements.

RFI cycle refers to the Request For Information loop between the receiving bank's compliance team (or the regulator's review team in a licensing context) and the applicant. After initial submission, the reviewer identifies gaps or inconsistencies in the documentation and sends a written request for clarification, additional documents, or amendments. The applicant responds, the reviewer evaluates, and if further questions arise the cycle repeats. Each cycle takes one-to-three weeks of elapsed time depending on the bank's or NCA's internal processes.

finconduit tracks RFI count as a core internal quality metric. Clean applications go through one or two RFI cycles before resolution. Messy applications go through four to six and often die in the loop without ever reaching a final decision — not because the underlying business is unsuitable, but because the cumulative time investment exhausts both the reviewer's patience and the applicant's runway. A six-RFI application that resolves positively still takes nine to fifteen months from initial submission to final answer, which for many fintech business plans is fatal regardless of the eventual outcome.

Reducing RFI count is therefore one of the largest values added by structured pre-application work. Every avoided RFI shortens the elapsed timeline by roughly two to four weeks. An application that goes from four RFIs to one cuts perhaps eight weeks off the timeline and gets the applicant to a banking relationship or a licence faster. The mechanism is simple: anticipate the questions the reviewer will ask and answer them inside the initial submission rather than waiting for them to surface.

The pattern of avoidable RFIs is well-documented. Inconsistencies between the Programme of Operations and the AML policy. Unclear funds-flow descriptions. Missing director references. Capital adequacy calculations that use one method when the supporting projections imply another. UBO documentation that describes the ownership structure as it stood six months ago rather than as it stands today. Each of these is a routine RFI, and each can be eliminated in advance by a careful pre-submission review. The RFI metric is the practice's ongoing test that the pre-submission work is doing what it should.

Bankability assessment is finconduit's structured form at /assessment that captures the prospective client's institution type, jurisdiction, banking history, regulatory licences, and stated challenge before any direct contact is made. It is a lead-generation tool that doubles as a triage filter. Some submissions are not a fit — the activity is outside our regulatory scope, the jurisdiction is one we do not advise on, the matter is a MATCH-listing question we do not handle — and we say so directly rather than treating every form completion as a sales opportunity.

The assessment is engineered so that the prospect receives a useful response within one business day regardless of whether the engagement turns into a paid relationship. A prospect that does not fit our scope still gets a clear answer about why and, where possible, a pointer to where they should look instead. A prospect that does fit our scope gets a structured conversation about the regulatory profile, the banking-access challenge, and the realistic timeline to resolve it. That conversation is not contingent on engagement; it is part of the practice's view of how regulatory advisory should work in a market where most operators have been bounced between firms that promise outcomes they cannot deliver.

The data captured in the assessment also informs how the practice maintains its banking-partner-readiness map. A submission from a Lithuanian EMI seeking USD-clearing relationships gets routed against the practice's current view of which banking partners are open to that profile this quarter. A submission from a Cypriot CIF seeking custody-account relationships gets routed differently. The assessment data is not just a lead-capture form; it is also a market-intelligence input that updates the practice's matching logic in close-to-real-time.

The form is intentionally opt-out for marketing communications. Submitting an assessment does not enrol the prospect in any newsletter, drip sequence, or nurture campaign. The single business-day reply is the only contact the prospect receives unless they explicitly engage further. That posture is non-standard in advisory marketing — most firms maximise the touch frequency post-form-submission — and is part of how the practice distinguishes itself from generic lead-generation operations.

MATCH (Member Alert to Control High-Risk Merchants) is a Mastercard-operated database of merchants that have been terminated by acquirers for serious reasons: chargeback-ratio breaches that exceeded scheme thresholds, fraud findings, AML breaches, illegal activity, or violations of card-network rules. Once a merchant is MATCH-listed, the listing becomes visible to every Mastercard acquirer that queries the database during onboarding, and getting onboarded by a new acquirer becomes extraordinarily difficult. Visa operates a parallel database (VMSS / Visa Merchant Screening Service) with similar mechanics.

Listings are not casual or commercial. They are made by acquirers based on defined reason codes, each of which corresponds to a specific category of termination. The reason codes vary in seriousness from "Excessive Chargebacks" (a comparatively recoverable category) to "Fraud Conviction" (a near-permanent listing). The reason code controls how new acquirers will read the listing and whether they will entertain re-onboarding at all.

Removal from MATCH is procedurally difficult. The acquirer who placed the listing controls whether to remove it, and Mastercard's rules govern when removal is permitted. The process typically requires the merchant to demonstrate substantive remediation — fraud has been resolved, chargeback ratios have been reduced for a defined period, regulatory issues have been settled — and the acquirer must agree that the original ground for listing no longer applies. The acquirer has limited commercial incentive to spend time on removal once the merchant is no longer a customer, which produces an asymmetry that benefits the listing party.

MATCH-related cases are outside the scope of regulatory advisory. The underlying issue is a merchant-services question, not a regulatory authorisation question, and resolving it requires direct dialogue with the listing acquirer and (where relevant) Mastercard. The practice mentions MATCH in content as one of the lasting consequences of mismanaged merchant programmes, but does not take engagements where the central work is removing a MATCH listing. Operators in that situation need a specialist merchant-acquiring consultancy, not a regulatory advisory firm. The practice can sometimes be useful as a parallel input — clarifying the regulatory and AML implications of the original termination, where they are relevant — but the merchant-side resolution work has to be done by a different specialist.

Sponsor bank is the US-specific structural concept under which a chartered bank "sponsors" a fintech to provide banking-like services to end users while the fintech itself is not a bank. The sponsor bank holds the deposit accounts of record, the regulatory licence, and the FDIC pass-through insurance arrangement; the fintech operates the customer-facing product, controls the user experience, and holds the commercial relationship. The sponsor bank carries the regulatory exposure to the OCC, the FDIC, the Federal Reserve, and (for state-chartered sponsors) the relevant state banking regulator.

The model has produced a meaningful share of US fintech innovation over the last decade — the prepaid-card era, the early neobanks, and a substantial portion of the embedded-finance category. It works because US bank charters are scarce and expensive, and because state-by-state money-transmitter licensing is operationally onerous. Sponsorship lets a fintech access regulated payment rails without holding either a federal bank charter or a fifty-state MTL stack.

The model is also less common in the EEA and UK, where direct EMI authorisation under EMD2 (or the FCA EMR equivalent) is usually a cleaner path. EMI authorisation is achievable in commercially reasonable timeframes through Bank of Lithuania, the FCA, and a handful of other NCAs; it gives the fintech direct authorisation rather than dependency on a sponsor; and it carries with it a passport across the EEA. The structural reasons that drive sponsorship in the US — bank-charter scarcity, MTL fragmentation — do not exist in the EEA in the same form.

Sponsor-bank structures appear in cross-Atlantic fintechs trying to serve both US and EEA customers, and they should be approached with caution. The layered US regulatory complexity is real: NYDFS may have separate views from the OCC, the FDIC's true-lender doctrine has tightened, state attorneys general have asserted jurisdiction over fintechs operating under bank-sponsor models, and the regulatory environment has shifted multiple times in the last five years. An operator structuring a US presence should expect to spend significantly more on US legal counsel than on EEA regulatory advisory, and should size the US compliance and regulatory-affairs function accordingly. The practice generally does not structure clients around sponsorship as the EEA-side answer, but advises clients with existing US sponsorship arrangements on the EEA-side regulatory implications.

Specialist crypto-native bank is the practice's category for banking partners that have explicitly built their compliance infrastructure to support digital-asset clients. They are distinct from Tier-1 commercial banks that have a "crypto desk" or are "running an experiment" in digital-asset client onboarding. The crypto-native bank's entire risk model, AML rule set, transaction-monitoring framework, and risk-appetite curve are designed around digital-asset clients from inception, not adapted from a retail-banking baseline.

The practical consequences are visible in onboarding speed and ongoing operations. A crypto-native bank's compliance team understands the difference between a CASP serving institutional liquidity providers and a CASP serving retail consumers, and applies different review protocols accordingly. It understands the transaction patterns of blockchain operations and does not flag every wallet-to-wallet rebalancing transaction as suspicious. It understands the difference between qualified custody arrangements and exchange hot-wallet flows, and treats them differently for source-of-funds review. None of those capabilities is impossible at a Tier-1 bank with a crypto desk; they are simply much more reliable at a bank where the entire institution is structured around them.

The trade-off is balance-sheet size and product breadth. Crypto-native banks are generally smaller than Tier-1 commercial banks, hold fewer correspondent banking relationships, and offer a narrower product set. A CASP that needs USD-clearing through a major US correspondent for global institutional flow probably cannot get that through a crypto-native bank alone. A CASP that needs a SEPA-Instant operating account, basic FX, and a card-issuance programme can get all of that from a crypto-native bank without difficulty.

The recommended pattern for institutional clients is to use a crypto-native bank as the operating bank — fast onboarding, relevant compliance posture, willingness to grow with the client — and a Tier-2 bank as the safeguarding bank, where the Tier-2 bank's broader balance sheet, more conservative risk posture, and stronger correspondent relationships are commercially valuable. Over a two-to-three-year horizon as the client matures, the safeguarding-bank role can be upgraded to a Tier-1 bank, while the crypto-native bank remains the operating bank because no Tier-1 commercial bank will replicate its sector understanding.

Qualified custody is the standard for crypto-asset safekeeping that satisfies regulator expectations under multiple frameworks: MiCA Article 70 in the EEA, the SFC framework in Hong Kong, UAE VARA, MAS guidelines in Singapore, and the BaFin crypto-custody licence regime in Germany. Across these frameworks, the substantive requirements converge on a similar core: cryptographic key segregation between client assets and proprietary assets, insurance coverage at meaningful limits, internal controls including dual-authorisation procedures for material movements, complete audit trail for every key operation, and (for EU and UK) bankruptcy-remoteness of client assets in the event of custodian insolvency.

The standard is not just "cold storage". Cold storage — the practice of holding cryptographic private keys in a manner not connected to the internet — is one component of qualified custody, but it is not by itself sufficient. A custodian that stores keys on air-gapped hardware modules in a vault but does not have segregation, does not have insurance, does not have dual-control procedures, and does not maintain audit trails is not a qualified custodian under any of the frameworks named above. The framework requirements address operational risk and counterparty risk in addition to security risk; cold storage addresses only the security component.

Vendors in the qualified-custody category include Fireblocks, BitGo, Anchorage Digital, Komainu, Bitpanda Custody, and Sygnum. Each operates under one or more of the regulatory frameworks named above and is structured to meet the framework's requirements. The vendors differ in client base (institutional versus retail-adjacent), supported assets (Bitcoin and Ethereum at minimum, with varying coverage of newer L1s and L2s), pricing model, and operational integration capability. Selection between them depends on the client's specific operational profile rather than on rank-ordering of which vendor is "best".

In casework, the practice does not name specific custody vendors in published content for the same reason it does not name specific banking partners: the editorial naming constraint preserves the relationships that produce favourable client outcomes. The category descriptions are public; the specific recommendations are made privately within engagements. CASPs structuring custody architecture should expect to evaluate at least three vendors in detail before selecting, and should expect the procurement timeline to overlap with the CASP licence application rather than being treated as a separate downstream workstream.

Substance over form is a tax-law principle that NCAs are increasingly applying when reviewing licensing applications and conducting ongoing supervisory inspections. The principle says that the legal characterisation of an arrangement does not control its regulatory or tax treatment if the substantive reality is different. A structure that looks compliant on paper — a "Lithuanian EMI" with a Lithuanian registered office, Lithuanian-resident directors on paper, and a Vilnius address — may fail the substance test if the directors do not actually live in Lithuania, the operations do not actually run from Vilnius, and the decisions are not actually made in the jurisdiction.

NCAs now apply substance-over-form reasoning at multiple points. At the licensing stage, they ask whether the substance described in the Programme of Operations matches the substance the applicant can evidence. At ongoing-supervision inspections, they ask whether the substance has remained as described or has drifted. At licence-renewal-equivalent reviews (in jurisdictions that have them), they ask whether the substance has scaled in proportion to the activity. Each point in the lifecycle is a potential substance test.

The hardening of the substance posture across the EEA is partly a response to the FATF mutual-evaluation process, which examines how each jurisdiction's NCAs detect and address substance gaps in licensed entities. Member states that received critical FATF feedback have, in turn, tightened their substance requirements and applied them more aggressively. Lithuania, Cyprus, Malta, and several other historically lighter-touch jurisdictions have all moved in this direction since 2022.

The implication for structuring is that substance is not a one-time check at the licensing point. It is a continuous obligation, and the cost of maintaining substance scales with the size of the regulated activity. A Lithuanian EMI that processed €50M of monthly volume with two local directors and three local employees may pass a substance review at that scale, but the same staffing at €500M of monthly volume may not. The advisory work includes substance-monitoring as part of ongoing engagement, with explicit reviews when activity materially changes, and with proactive substance up-scaling rather than waiting for a supervisory inspection to surface a gap.

De-banked and unbanked describe two different problems that look similar from outside but require materially different evidentiary approaches. A de-banked entity had a banking relationship and lost it — usually because of de-risking, account closure, or a bank policy change. An unbanked entity never had a banking relationship in the first place. Mixing the two profiles in a single application strategy is a common error that leads to either understated risk (treating a de-banked entity as if it were a clean first-time applicant) or overstated risk (treating an unbanked entity as if it had a problematic banking history).

The de-banked entity has a "what changed" question to answer for the next bank. Why did the prior relationship end? What was the precipitating event? Was the cause a problem with the entity's own conduct (in which case the new bank wants to see remediation), or was the cause something external (correspondent pressure, supervisory examination at the prior bank, a CRO change at the prior bank)? The new bank cares enormously about this question, and the answer needs to be available, well-evidenced, and consistent with whatever public information the new bank can find. A de-banked entity that cannot give a coherent explanation looks worse than an unbanked entity, because the absence of an explanation is itself information.

The unbanked entity does not have the "what changed" question, but has a fresh-start credibility hurdle: why is the entity ready for a banking relationship now, when it has not had one before? For a newly licensed EMI, the answer is straightforward — the licence itself is the credibility event. For a longer-running business that has operated through alternative payment arrangements, the answer is harder, and may involve accounting for why prior banking relationships were not pursued.

In application strategy, the two profiles get different documentation. The de-banked profile leads with the closure narrative — what happened, how the entity has corrected for it, what the new bank can rely on. The unbanked profile leads with the readiness narrative — what makes the entity ready now, what governance and operational maturity has been put in place. Both narratives need to be supported by documentary evidence, but the documentary evidence emphasises different things. Conflating the profiles in a single template-driven application is a frequent source of avoidable RFIs.

Banking partner risk appetite as the dominant variable is the methodological commitment that runs through the practice's banking-introduction work. The commitment is that licence type, business model, and capital adequacy are necessary but not sufficient determinants of banking outcome — and that the most explanatorily powerful variable is which banking partner the application lands at and how the application is framed for that specific partner.

The evidence for the commitment is the spread of outcomes within similar client profiles. Two CASPs with identical MiCA authorisations from the same NCA, with equivalent capital, equivalent management, equivalent activity profiles, and equivalent compliance programmes, can have wildly different banking-access experiences. One closes a Tier-2 banking relationship in six weeks; the other has six declines from comparable banks over four months. The difference is not their licence type, their AML programme, or even their lawyers. It is the partner they were matched with and the way the application was framed.

The methodological consequence is that banking-introduction work is a partner-selection-plus-presentation-engineering exercise, not a template-completion exercise. A correctly matched application from a Cypriot CIF can succeed where an incorrectly matched application from a German EMI fails, even though the EMI looks objectively stronger on paper. The CySEC-licensed firm wins because the partner it was introduced to had a clear positive disposition toward CIFs in that activity range. The German EMI loses because it landed in front of a partner whose policy was tightening on EMIs that month.

This commitment also explains why the practice does not maintain published banking-introduction "success rates" by licence type. The success rate is meaningfully a function of the partner pool the introductions were routed to, not of the licence type alone. Reporting success rates without controlling for partner-pool selection produces misleading numbers that other operators may use to compare advisory firms unfairly. The practice tracks pre-approval rate (87%) and formal rejection rate post pre-approval (under 8%) as more honest metrics, because both control for partner selection by definition: the pre-approval has already been obtained from a specifically matched partner.

Pre-application engagement as a jurisdictional signal is the practice's working theory that the availability and quality of informal pre-submission meetings tells the operator more about an NCA's likely conduct during the substantive review than most other publicly available signals. The theory is empirical rather than ideological: across the engagements where the practice has run substantive licensing work, jurisdictions that offered real pre-application engagement produced more predictable timelines, clearer feedback, and faster resolution than jurisdictions that did not.

The mechanism behind the signal is straightforward. Pre-application engagement is staff-time-expensive for the NCA. A supervisor who agrees to spend an hour or two reviewing a prospective applicant's business model in advance of submission has made a judgement that the prospective applicant is sufficiently serious to warrant the time. NCAs that consistently make that judgement are signalling that they want to authorise good firms, that they are willing to invest staff resource in shortening the review cycle, and that they are commercially reasoned in subsequent reviews because they have already absorbed the strategic context of the application.

NCAs that do not offer pre-application engagement, or that offer a fifteen-minute formality with no substantive feedback, are signalling something different. They may be under-resourced, in which case timelines will be long. They may be procedurally rigid, in which case RFI cycles will be expensive. They may have no commercial intent toward the applicant category, in which case the application has a low base-rate probability of success. None of those signals is necessarily disqualifying, but each has implications for how the application is structured and what timeline expectation the applicant should set.

In the practice's jurisdictional matching work, availability of pre-application engagement is therefore one of the four primary criteria — alongside processing time, substance burden, and language/operational geography. Jurisdictions where pre-application engagement is real (Bank of Lithuania, Cyprus on a selective basis, Malta on a selective basis, the Central Bank of Ireland for serious applicants) get routed first when other factors permit. Jurisdictions where it is absent get used only when other factors specifically favour them.

The 87% / sub-8% pair is the two-metric test that finconduit uses to validate that its banking-introduction methodology is doing real work rather than being a polite filter that the formal stage would have caught anyway. The first metric is the pre-approval rate: 87% of pre-positioned introductions result in a positive informal indication from the receiving banking partner. The second metric is the formal rejection rate post pre-approval: under 8% of pre-approved applications subsequently fail at the formal-application stage.

The two metrics are deliberately reported together because either alone would be misleading. A 100% pre-approval rate is suspicious — it suggests the pre-approval process is not actually filtering, and that the partner is approving everything that arrives. An 87% pre-approval rate with a 30% subsequent formal rejection rate would also be suspicious — it would suggest the pre-approval is generous and the formal stage is doing the actual screening. Neither pattern is what the methodology is supposed to produce.

The 87% / sub-8% pair shows that the pre-approval is doing the work. The pre-approval accepts most of what it reviews (87%), which is consistent with a well-matched partner pool — the introductions are being routed to partners with positive base-rate disposition toward the client profile. And the post-pre-approval formal rejection rate is genuinely low (under 8%), which is consistent with the pre-approval substantively predicting the formal outcome rather than acting as a procedural courtesy. The combination implies that the matching exercise plus the pack preparation are doing the heavy lifting before the formal stage begins.

The metrics also have validation power against alternative methodologies. A generic banking-introduction service that simply forwards applications to multiple banks without a structured pre-approval step typically reports headline acceptance rates in the 30-50% range. A practitioner approach that runs structured pre-approval should produce materially better numbers, and finconduit's pair of metrics is the practice's empirical demonstration that the structured approach is working as intended. The metrics are tracked continuously and reviewed quarterly; if either metric drifts materially the practice reviews the matching logic and the pack-preparation process before continuing the introduction work at scale.