Pay Contractors in Greece: IRIS Rules and Launch Checks

What to check before you launch IRIS contractor payments in Greece#

Treat Greece as a bank-first validation exercise, not a quick payment toggle. The confirmed facts here are useful but narrow. They support IRIS for e-shop acceptance, not a full rulebook for contractor payouts.

1. Separate confirmed facts from payout assumptions.

Alpha Bank documented scope is e-shop acceptance: customers pay a business from their bank account through e-Banking, and the business gets immediate payment notifications. That helps you map customer collection and merchant acceptance. It does not, by itself, validate contractor disbursement design.

1. List unresolved items before you estimate the build.

The material here does not include primary Bank of Greece text for contractor-specific IRIS treatment. Keep the unknowns explicit: contractor classification, cross-border treatment, settlement timing, enforcement mechanics, and payout-specific reversals or exception rules.

1. Use the clearest supported dependency as your first checkpoint.

The strongest operational evidence is Alpha Bank's 3-step e-shop flow, including DIAS registration and an integration test before go-live. Get written confirmation from your bank or provider on whether they support e-shop acceptance, contractor payouts, or both, and what exact test or approval marks readiness.

1. Lock scope before architecture.

Confirm the use case first: merchant acceptance or contractor payment. Then separate what is documented from what is still open, and only then choose the integration and reconciliation design. That prevents avoidable rework across product, ops, and compliance.

A common failure mode is treating merchant-acceptance material as payout design guidance. Here, "IRIS Payments in e-shops" is the scope boundary. Skip that check and you risk building the wrong request flow, status model, and reconciliation logic.

Start an evidence pack on day one: bank product description, DIAS registration step, integration test result, and a short log of open questions pending bank or regulator confirmation. The rest of this guide follows that sequence: confirm what is supported, isolate what is still unverified, lock dependencies, then commit to integration and controls.

Decide if Greece is launch ready for your contractor model#

Treat Greece as conditional for contractor payouts. Proceed only when your bank path and the open regulator questions are confirmed in writing. In practice, that means the launch is governed by evidence completeness, not market interest.

Use the broader market context only as background. Your launch decision should still hinge on written bank scope, DIAS setup, and unresolved regulator questions for contractor payouts.

Step 1 Build a go/no-go matrix before budgeting#

Use one matrix to separate evidence from assumptions and assign owners before you spend.

If any row still has unresolved scope and no named mitigation owner, treat the launch as no-go.

Step 2 Split payout design from merchant acceptance#

Budget contractor payouts and checkout acceptance as separate tracks. Shared country or bank context does not make the two models interchangeable.

The clearest grounded example here is NBG's integrated service: acquiring plus invoicing, SME and self-employed focus, and next business day settlement. That helps with acceptance planning. It does not, by itself, prove a contractor payout design.

Step 3 Apply a hard stop on reversal assumptions#

If your model depends on automated refunds or cancellations inside the provider flow, pause launch until your bank confirms that capability for your path. The material here does not support treating gateway-native reversals as already solved for contractor payouts.

Get written answers on who initiates reversals, which transaction types are eligible, and how operations will handle exceptions. Without that, your exception model is not launch-ready.

Step 4 Gate leadership approval on evidence completeness#

Do not take an expansion decision to leadership until scope and timing conflicts are resolved against primary bank or regulator documentation in Greece. This matters operationally because documented bureaucracy and court delays can extend unresolved issues.

Before approval, require an evidence pack with the following:

If that pack is incomplete, the decision is not launch-ready.

Confirm what is regulated today and what is still unverified#

Treat Greece as partially verified. IRIS product behavior is documented, but contractor-specific regulatory scope is still unconfirmed.

Step 1 Record the effective-date question as unresolved#

The material provided here does not establish a legally binding effective date for any IRIS acceptance obligation. Keep that gap visible in the decision log, assign an owner, and do not treat any date assumption as launch-ready until your bank or regulator confirms it in writing.

Step 2 Separate product behavior from regulatory scope#

Use product facts for implementation planning, not as proof of contractor-payout regulation. In the evidence provided, Alpha Bank describes IRIS flows for paying businesses, including initiation by tax number, registered mobile number, or QR, plus activation dependencies for the relevant parties. It also lists product limits such as up to €1,000 for certain flows and up to 15 daily transactions without bank fees.

Those are useful checkpoints, but they are still product-level characteristics from that source, not a confirmed Bank of Greece rule for contractor payouts.

Step 3 Keep regulator provenance as a live risk#

The material here does not include primary Bank of Greece text on contractor-specific treatment. That leaves classification handling, merchant-acceptance equivalence, and cross-border treatment open from a regulator-proof standpoint.

Secondary legal commentary can help frame the issue, but it cannot replace primary rule text for launch sign-off.

Step 4 Keep known unknowns in the main record#

Keep these open items visible until they are closed in writing:

• contractor classification handling
• cross-border payout treatment
• settlement SLAs for the actual contractor flow
• enforcement mechanics beyond secondary summaries

If any of these points is material to your first release, treat it as a hard gate before build and launch.

Prepare prerequisites before any build starts#

Start with the prerequisites you can verify now, and treat bank-specific items as open until they are confirmed in writing. In Greece, the grounded blockers are legal setup, registration evidence, and reporting readiness.

Step 1. Lock your legal operating assumption first. Document your operating model for Greece and lock that assumption before integration starts. Your baseline evidence should cover business registration with GEMI and tax authorities, including relevant e-commerce KADs, plus the core disclosure fields: legal name, address, VAT, and GEMI number. There is no distinct e-commerce regulator registration unless you provide electronic communication services.

Step 2. Convert bank onboarding unknowns into written confirmations. Do not assume contractor flows require a local Greek IBAN, a DIAS code, Annex A - DCT Creditor Parameters, or Payment Code Standard RI0. Treat each item as unverified and request the exact required documents, identifiers, and account setup in writing before you scope build work.

Step 3. Confirm reporting dependencies before sequencing product work. The grounded requirement is mandatory electronic reporting of accounting and invoice data with QR codes through the myDATA platform. If market guidance references additional authority-linkage requirements, keep them unverified until your bank or tax adviser maps them to your actual registration and reporting model.

Step 4. Assign non-engineering owners at the start. Put product, compliance, and finance ops on the critical path immediately. Compliance should own the legal basis note and any disclosure obligations that affect your flow. Finance ops should own registration and myDATA readiness evidence. Product should own the dependency log for unresolved bank prerequisites.

Related reading: How Platform Operators Pay Contractors in Colombia with PSE Nequi and DIAN Controls.

Sequence bank and platform onboarding in the right order#

Set the sequence from written bank confirmation, not assumptions. The material here does not establish a universal Greece rule that bank activation must always come first, and it does not provide direct evidence for a fixed Greece contractor-payment onboarding sequence.

Step 1 Choose a primary and fallback counterparty first#

If your shortlist includes Alpha Bank, National Bank of Greece, Eurobank, Piraeus Bank, Viva.com, or Credia Bank, treat that as a diligence list only. The available material does not confirm any of these as validated routes for this contractor flow, and it does not confirm contractor-specific treatment under Bank of Greece rules for this workflow.

Before you commit delivery dates, get written onboarding scope from one primary path and one fallback: enabled product, account structure, required documents, issued identifiers, and test and support contacts. If that scope is unclear, keep engineering scope flexible.

Step 2 Confirm identifiers and parameters in writing before scaling build work#

Do not assume DIAS code issuance, Annex A items, or Payment Code Standard RI0 requirements. Ask the selected counterparty which identifiers and parameters apply to your flow, when they are created, and which fields are fixed versus configurable.

Use a documentation checkpoint, not verbal confirmation: written approval, required identifiers, parameter rules, and expected rejection handling. If these are incomplete, keep implementation narrow and avoid locking payment logic.

Step 3 Reallocate work when onboarding stalls#

If bank onboarding slips, you may choose to pause nonessential frontend work that depends on unverified bank behavior. Redirect effort to reconciliation, exception handling, reference storage, and operator tooling that will still matter even if the banking path changes.

Prioritize what improves traceability under uncertainty: separate reference fields, unmatched-item queues, operator notes, and evidence storage for onboarding artifacts.

Step 4 Add a verification gate after approval and before go-live#

After onboarding approval, run a controlled matching test before production. If your workflow depends on settlement files, statement fields, or Adyen mapping, validate those artifacts with your actual counterparties rather than assumed formats.

Use a small test set with a successful case, a failed or rejected case, and a manual-review case. Confirm identifier consistency across platform records, statements, and finance operations. If matching still depends on manual interpretation, consider delaying go-live until rules are explicit.

Related: What Is Bank Remittance? How Platforms Send Payment Advice to Contractors.

Choose the right integration path for your channels#

Choose channels from current written evidence, not assumed product readiness. In the provided excerpts, there is no confirmed basis to treat Checkout API as the online default, Drop-in/Components as supported, or Verifone Engage terminals as in-store ready for this Greece contractor flow. Treat these integration paths as unverified until you have dated written approval.

Step 1 Verify channel support with dated written approval#

Do not set online-first or in-store-first based on marketing language, legacy tickets, or naming familiarity. In the provided excerpts, channel support and contractor-specific Bank of Greece integration rules are unknown.

Get one dated confirmation per channel from the responsible counterparties: supported product, environment availability, dependencies, exclusions, and launch owner. Check the document date, confirm whether updates exist, and store the artifact in your evidence pack. If approval is only verbal, treat the channel as unapproved.

Step 2 Set launch order by unresolved dependencies#

Rank channels by what is still unknown or externally blocked, not by ambition. If a route depends on unconfirmed hardware, firmware, component support, or bank-side behavior, treat those as blockers until they are resolved in writing.

Launch the channel with fewer unresolved dependencies and clearer written evidence. Expand only after the next channel meets the same evidence bar.

Step 3 Lock engineering checkpoints before build commitment#

Because IRIS-specific integration mechanics are not confirmed in these excerpts, use an internal checkpoint list before scaling implementation, for example:

• payment request creation flow and mandatory fields
• callback or webhook availability and expected event set
• status mapping into internal states, including pending, failed, completed
• idempotent retry behavior to prevent duplicate money movement
• reconciliation reference fields that persist into downstream finance matching

If any checkpoint is still vague, keep scope narrow and prioritize reference storage and exception handling over channel UX polish.

Step 4 Expand only after end-to-end validation#

Treat additional channel paths, including Drop-in/Components or terminal expansion, as phase-two work unless current written approval exists for your exact setup. Expanding on unapproved paths increases rework risk across engineering, finance operations, support, and compliance.

Before broadening scope, require a complete evidence pack: dated support confirmation, request and event test results, reconciliation samples, and any device or version approvals needed for in-store flows.

Design payout and reconciliation controls before first live transaction#

Finance controls should be production-ready before launch, not patched in after the first volume. If you cannot show how a payment appears on a statement, maps to a contractor record, and moves through exception handling, pause go-live.

Step 1 Anchor your ledger to statement evidence, not product assumptions#

Design reconciliation around records you can inspect: your internal payout record, provider reference, and bank statement output after posting or settlement. Do not hardcode IRIS or provider behavior from informal notes. In this material, contractor-specific IRIS reconciliation mechanics are not confirmed.

Use one approved test case as a gate: finance should be able to trace amount, beneficiary, date, and status end to end without engineering support. If that trace fails, the ledger model is still too thin.

Step 2 Normalize initiation paths into one payout record#

Use one accounting shape for every initiation path. Keep the contractor payout as the primary ledger object, and store initiation details as metadata so reconciliation logic stays consistent.

Minimum record fields should include internal payout ID, contractor ID, amount, currency, created time, execution status, provider reference, and any external reference you receive. Keep channel details queryable, but separate from the core money-movement fields.

Step 3 Build exception queues before volume arrives#

Define exception handling on day one for unmatched items, delayed postings, and duplicate-event replays. These three queues provide a practical baseline for payout operations and keep investigations bounded.

Keep internal and external references searchable by operations, even when counterparties use different field names. If routine traceability depends on engineering log review, the control design is incomplete.

Step 4 Send beneficiary updates only from verified states#

Notify contractors only from states you can defend with evidence. A "completed" message should map to a documented confirmation rule, not just request creation.

Keep notification wording conservative until posting behavior is proven. Before first live traffic, assemble one review pack with statement samples, reference-mapping examples, duplicate-handling tests, and beneficiary message rules. DIAS reporting areas such as business continuity, personal data, credit risk, and the Independent Certified Auditor's Report are a useful checklist for that pack.

Handle refunds cancellations and exceptions without breaking contractor trust#

Treat refunds and cancellations as potentially bank-dependent until your bank confirms a specific path in writing. If your current flow cannot complete a reversal in platform, do not promise a one-click cancellation outcome to contractors.

Step 1 Classify the exception before promising a result#

Label the case first as a reversal request, duplicate payout, or make-good correction. Keep those paths separate so support does not describe a "cancellation" when the practical fix is a separate correcting payment.

Before any bank escalation, confirm the case record includes internal payout ID, contractor ID, amount, execution date, provider reference, and any bank or DIAS reference you already captured. If those identifiers are incomplete, keep the case in internal investigation.

Step 2 Use controlled corrective flows when reversal is uncertain#

When reversal is not confirmed, resolve the contractor outcome through an approved compensating flow with clear ownership and case tracking. Send one clear message that explains what is known, what is pending, and what you control next.

Keep "bank review" status separate from any corrective payment decision. That separation reduces the risk of creating a second exception if the original transfer later posts or is returned.

Step 3 Set expectations around dependencies you can prove#

Commit to internal response timing and update cadence, not bank completion timing you cannot verify. Promise only what your team controls: case creation speed, evidence completeness, escalation timing, and update frequency.

That boundary matters with the material here: the available DIAS and Bank of Greece public material helps with scheme and oversight context, but it is not a contractor-specific reversal manual.

Build the compliance evidence pack for internal and external review#

Launch approval should be a maintained evidence pack, not a meeting outcome. If you cannot show what is confirmed, what is unresolved, and who owns each open item, the rollout is not review-ready.

Step 1 Separate confirmed points from open assumptions#

Build one launch file with three buckets: confirmed by source, confirmed in writing by your bank or provider, and unresolved. Keep regulatory notes, written confirmations, claimed dependencies, and open regulator questions in the same file, with an owner, date raised, next action, and due date for each open item.

Use the current Greece context as a reason to stay strict. Payment scope, onboarding, and regulator interpretation can shift across counterparties and updates, so assumptions can age quickly.

Step 2 Keep control evidence that proves payout traceability#

Your pack should show the control chain for each payout: screening, approval, submission, and traceability to settlement. Where your process includes controls such as KYC/KYB gates, approval logs, idempotency handling, and audit-trace links, keep evidence from request to final reference.

Run a practical check with sample successful and failed or retried payouts, and confirm each handoff can be reconstructed from system records rather than inboxes or chat history.

Step 3 Store onboarding artifacts with live operating evidence#

Keep onboarding proof in the same pack as operating controls. If your bank or provider path uses items such as Annex A - DCT Creditor Parameters, DIAS code records, or Checkout API or terminal integration test evidence, store each artifact with its source, version or date, and owner.

Frame these as route-specific dependencies unless they are separately confirmed as mandatory for your exact contractor use case.

Step 4 Review on a fixed cadence and close open items#

Set a recurring review cadence and refresh immediately when bank, provider, or legal inputs change. Use each review to retire stale assumptions, re-check unresolved regulatory items, and confirm whether bank or provider dependencies are still unverified.

This discipline matters because payment-scope assumptions, onboarding dependencies, and reporting obligations can drift apart quickly when multiple counterparties are involved.

If your launch gate now depends on audit-ready payout controls and exception visibility, review the Payouts module before final sign-off.

Common rollout mistakes in Greece and the fastest recovery path#

The fastest recovery path is to treat every external dependency as evidence, not assumption. In practice, that means dated written confirmations, clear owners, and separate decisions by flow and by channel.

Step 1 Reset the plan if you treated IRIS like a simple PSP toggle#

If your plan treats IRIS scope as settled without written confirmation, reset it. For Greece launch planning, treat IRIS and DIAS sequencing, and any Bank of Greece interpretation, as open until your bank or provider confirms your exact setup in writing.

Convert each dependency into a dated line item with owner, evidence, and unblock condition. If you cannot point to a document or written confirmation, keep it marked unresolved.

Step 2 Fix reconciliation before volume grows#

Do not go live without agreed transaction references from day one. Recovery means backfilling mapping keys for in-flight records, then enforcing reference capture on every new transaction.

Use one queryable record per transaction so operations can trace successful, failed, and retried flows end to end. The checkpoint is simple: finance should be able to match each case from request to settlement evidence without rebuilding the story from inboxes.

Step 3 Split release plans by channel, not by brand name#

Do not assume one approved integration means all channels are ready. Keep separate release tracks for each channel in scope, each with its own test evidence, rollback criteria, and go-live sign-off.

Mark a channel live only when that channel's own evidence pack is complete. Cross-channel assumptions are where avoidable rollout delays usually show up.

Step 4 Separate contractor payouts from merchant acceptance in policy#

Keep contractor disbursements and merchant acceptance in separate policy notes. The material here does not confirm that these two flows should be treated as one policy assumption.

For each note, list confirmed points, open questions, and document impacts. Where relevant to your model, include myAADE filing dependencies, K.A.D. declaration with simultaneous VAT-status registration, penalty exposure for late or missing declarations, and e-invoicing timing under Decisions A.1128/2025 and A.1129/2025, including 2 February 2026 for entities above EUR 1,000,000 FY2023 revenue and 1 October 2026 for others.

Conclusion#

The right move in Greece is staged certainty, not speed. Clear each bank, legal, and operations dependency before you commit more build effort.

Use this as your go or no-go sequence:

1. Verify mandate scope and timing from primary sources. Review current legal material alongside your bank's latest IRIS documentation, and document where they align or conflict. The evidence here supports IRIS for direct bank-account e-shop payments, but not contractor-payout-specific treatment or a definitive mandate date.

2. Finish bank onboarding and DIAS registration before engineering-heavy work. The published sequence is explicit: sign the DIAS registration agreement first, then receive technical instructions to link the e-shop to IRIS. Treat that order as a hard dependency.

3. Choose one launch channel and prove it in an integration test. Do not run parallel channel plans until one path is evidenced end to end. The grounded pre-launch checkpoint is a successful integration test confirming the link is complete.

4. Implement reconciliation and exception handling before live volume. Immediate payment notifications support monitoring, but they are not reconciliation. Require reference persistence, status handling, and a queue for unmatched items so support, finance, and product can trace the same transaction with the same identifiers.

5. Approve launch only with a complete compliance evidence pack. Keep onboarding proof, DIAS registration records, integration test evidence, and Greece legal notes together. Include review of mandatory online information disclosures and your current legal-basis memo before go-live, not after.

If one of these proofs is missing, pause. Confirm what is true now, isolate what is unresolved, and launch only when the bank path and evidence chain are complete.

When you are ready to validate Greece rollout assumptions against your operating model, talk with Gruv.