Open source marketing automation for financial services: why the build changes
A marketing lead at a bank, insurer or wealth firm often needs to run lifecycle campaigns without sending customer financial data to a US marketing SaaS. Self-hosted Mautic can meet that need, but only if approval, retention, consent and data boundaries are designed in from the start, not added after the first campaign goes live. The build changes because a financial promotion is a regulated communication, and because a marketing tool that sits next to customer records becomes part of the institution's ICT third-party estate, with the contract, location and exit obligations that come with it.
Two rule sets drive most of the design. The first is promotion control: many jurisdictions require a named approver to sign off a financial promotion before it is sent, and the approved version must be the one that was sent and kept. That means the campaign, template and segment must be versioned, approval must be recorded against them, and retention must hold the exact message, audience and send time. The second is ICT third-party risk. Under the EU's DORA (Regulation (EU) 2022/2554), which has applied since 17 January 2025 to entities including credit and payment institutions and insurers, the marketing platform and its hosting provider appear in the register of information, and the contract must state where data is processed and how it is returned or deleted. Confirm with your legal and third-party risk teams which other regimes, such as national marketing rules or US state privacy law, apply to your entity.
On platforms, the short answer is that Mautic should be the marketing engine, and the CRM and CMS should be chosen around it. Mautic handles segments, campaigns, consent records and suppression, so keep customer financial holdings, account balances and card or payment data out of it entirely, and pass only the attributes a campaign needs. The CRM remains the system of record for relationships, and the website CMS remains the home of the approved disclosures that every promotion must link to. Choose those components with the same third-party and exit questions in mind, because each one adds a data flow that your register and exit plan must cover.
Which financial rules shape campaign requirements
This table maps the financial rules most likely to reach a marketing environment to the concrete Mautic build decisions they influence. Read each row as a question to answer with your compliance, risk and IT teams, not as a claim that Mautic meets the rule. The main takeaway is that most obligations land on your processes, access model and data design, so the build must be scoped around them from the start.
| Rule or control | What it means for the Mautic build | Evidence to prepare |
|---|---|---|
| DORA Article 28(3) register of information | Record Mautic and every connected service (sending provider, CRM sync, hosting, support partner) as ICT contractual arrangements | Current register entries and named owners for each marketing-side ICT service |
| DORA Article 28(8) exit strategy | Plan how contacts, consent history, campaigns and suppression lists are exported and moved if Mautic or a provider is replaced | Tested export of contacts with consent and suppression data, plus a written transition plan |
| DORA Article 30(2) contract terms | Confirm in writing where contact data is stored and processed, including backups and sending infrastructure, and how data is returned on termination | Contract clauses on data location, change notice and data return, checked against the hosting design |
| FTC Safeguards Rule, 16 CFR 314.4(c)(5) | Require multi-factor authentication for every Mautic user account and remote admin path, unless the Qualified Individual approves an equivalent control in writing | Documented MFA settings, the written exception record if one exists, and the list of accounts covered |
| SEC Release 33-8810 access and change control | Restrict who can change campaigns, approval rules, segments and send configuration, and log those changes for review before campaigns go live | Role assignments, change records for campaign and configuration updates, and periodic access reviews |
| PCI DSS v4.0.1 scope | Keep cardholder data and sensitive authentication data out of Mautic entirely, so the marketing environment is not part of the cardholder data environment; confirm this with your QSA | Data flow diagram, field mapping showing no card data, and a network boundary between marketing and payment systems |
| GDPR consent records | Store the consent source, timestamp and wording with each contact, apply suppression before every send, and process withdrawal and objection requests in the same workflow | Consent log export, suppression audit trail and tested withdrawal procedure |
| Approval of financial promotions before send | Build an approval step in the campaign workflow where a named reviewer signs off content and audience before the send is released, and retain the approved version | Approval records linked to each campaign, with the reviewer identity and the version sent |
Which open-source options fit a regulated campaign stack
A regulated campaign stack usually pairs one campaign engine with a content layer and a CRM that holds the customer record. The choices below decide where consent, approvals and financial data sit, so each card names the decision and the check that should happen before a platform is selected.
Mautic as the campaign engine
Mautic is GPL-3.0 licensed, and the software itself has no paid edition, so license cost is not the decision here. The version and support window are. Version 7.2.1 was published on September 23, 2026, and 7.2 receives security support only until September 30, 2026. Version 7.3 is planned as the long-term support release with security support through December 31, 2027. Confirm the support window in writing before you go live.
PHP and database requirements
Mautic 7.0 requires PHP 8.2, 8.3, 8.4 or 8.5, MySQL 5.7 or higher with InnoDB or MariaDB 10.2 or higher, and a supported web server. Npm is needed from Mautic 5.0 onward. These requirements set your patching path, so confirm which PHP version your security team can keep supported. Ask your partner how they will test each minor release against your database version before it reaches production.
Hosting and shared hosting limits
The Mautic project states that it should not be installed on shared hosting and recommends a VPS or dedicated server. For a bank or insurer, this usually means a dedicated environment inside your own cloud account or data center, with separate application and database tiers. Confirm where backups, logs and cron-driven processing run, because segment updates, campaign triggers and queued email all depend on scheduled jobs.
CMS for landing pages and forms
Drupal 11.4.10 and WordPress 7.1.3 are both realistic choices for the public landing pages and forms that feed Mautic, but neither is a campaign engine. Drupal 11.x receives feature releases every six months, while WordPress.org maintains only the latest release in each series. Confirm the license terms, plugin and module review process, and support window for whichever you select, and check that form data reaches Mautic without storing account or product details on the public site.
CRM as the customer record
Mautic holds contacts for campaigns, but the customer record, account status and product holdings usually belong in the CRM that your advisers already use. Mautic offers HubSpot and Salesforce plugins, which you should review against your own data model before use. Decide which fields sync, which stay in the CRM, and which should never leave core systems. This keeps the marketing tool free of customer financial data.
Hosted services and managed Mautic
Managed Mautic and hosting services are promoted on mautic.org alongside the free self-hosted download. For a regulated firm, the question is not the vendor's brand but the contract: where data is stored, who holds administrative access, how backups are restored, and what happens to contact data on exit. Ask any hosting provider for these terms in writing and compare them with a self-hosted deployment in your own infrastructure.
How a financial services rollout runs in phases
The sequence moves from data classification and contract review to a controlled go-live, so each control is designed, tested and evidenced before any customer receives a campaign. Each phase closes with a written output that the next phase depends on. Durations are agreed in the written scope.
Classify data and define campaign scope
Map which data fields a campaign needs, which stay in the core banking, insurance or wealth systems, and which customer categories are in or out of scope, such as account holders, prospects and former clients. Classify each field by sensitivity and name a data owner for each. The output is a signed data classification register and a campaign scope statement that states which financial data never enters Mautic. Done when the compliance and business owners have both signed it.
Review third-party and contract terms under DORA
For EU-regulated entities, record the hosting provider, the email sending service and any integration vendor in the register of information. Under DORA Article 30(2), each ICT services contract must state where services are provided and data is processed, give advance notice of changes, and cover data return on insolvency or termination. Confirm these terms with your legal and third-party risk teams. The output is a contract checklist with a clear pass or gap result for each provider.
Design hosting, network and sending infrastructure
Design the dedicated environment for Mautic, which the project says should not run on shared hosting, so a VPS or dedicated server is the starting point. Define network segmentation between Mautic, the CRM connector, the database and the mail relay, plus admin access paths and logging. Confirm supported PHP, MySQL or MariaDB and web server versions against the official requirements before procurement. The output is an architecture diagram, a sending domain plan with SPF, DKIM and DMARC records, and a sign-off from security.
Install Mautic with cron and messenger jobs
Install Mautic from the production package or Composer template in the approved environment, then configure the cron jobs for segment updates, campaign updates and campaign triggers, staggered as the documentation advises. Add the broadcasts command for segment emails and a messenger consumer for queued email. Run a monitored test to confirm each job completes and logs its results. The output is a runbook with job schedules, alert thresholds and a tested restart procedure.
Build the consent and suppression model
Define how consent is captured, which lawful basis applies to each campaign type, and how unsubscribe, withdrawal and suppression are recorded and honored across segments and integrations. Set suppression rules for customers under complaint review, restricted products or regulatory holds. Test that a withdrawal propagates to every active campaign. The output is a consent matrix, a suppression policy and test evidence showing that suppressed contacts receive nothing.
Configure approval workflow and retention rules
Set up a staged approval flow in which a named compliance reviewer approves each financial promotion before any scheduled send, with the approval record, reviewer identity and version of content stored. Define retention periods for sent communications and approval records with your records management team, and configure archiving that preserves the exact content and recipient list. Test that a campaign cannot be dispatched without approval. The output is an approval procedure, a retention schedule and a test log.
Integrate CRM and minimize data flows
Connect Mautic to the CRM using only the fields defined in the classification register, with field-level mapping, sync direction and deduplication rules documented. Keep account balances, transaction history, card data and similar financial records out of the marketing database, and confirm with the test team that no payment card data enters scope. Under PCI DSS, any system that could affect the cardholder data environment must be assessed, so exclude card data paths entirely. The output is an integration specification and a data flow diagram that matches the register.
Test controls and review access
Run functional tests for campaigns, consent, suppression and approvals, then security tests on the Mautic instance, its admin interface and integrations. Review administrator, operator and reviewer accounts, enforce multi-factor authentication for every user with access to customer data, and document any equivalent control approved in writing. Record results against each control in the control matrix. The output is a test report with defects closed or accepted in writing, and a signed access review.
Go live in a controlled release
Start with a limited internal or low-risk audience, monitor send results, suppression behavior and cron health, and expand only after the owners sign off each stage. Keep the rollback path and incident contacts ready, and schedule the first review of the approval and retention records. Hand over the runbook, control matrix and evidence folder to the operating team. The output is a go-live record, a handover pack and a dated plan for periodic access and control reviews.
How deployment constraints differ by firm type
Retail and commercial banks usually hold the most sensitive customer data in this group, including account balances, card data and transaction history. Their marketing teams often need to link campaigns to product holdings, which raises the bar for keeping account and card data out of the marketing database. Approval intensity is typically high, because product promotions pass through compliance, legal and sometimes a financial promotions review before any send. Many banks in the European Union are DORA entities, and some also use Swift for payments, which can bring the Swift Customer Security Controls Framework into scope. Card data handling can bring PCI DSS into scope if the marketing environment could affect the cardholder data environment.
- Data sensitivity: Account and card identifiers should stay in the core banking or CRM systems, with only pseudonymous keys or approved segment flags reaching Mautic.
- Approval intensity: Expect pre-send review of every promotional template and audience, with a recorded approver for each campaign.
- DORA status: EU-licensed credit institutions fall under DORA, which requires a register of ICT contracts and tested exit plans for ICT services that support critical functions.
- Swift and PCI DSS scope: Swift users must assess controls annually, and any system that touches payment data may need PCI DSS scoping.
- Hosting location: Contracts must state where data is processed, so confirm the hosting region for every component.
Confirm with your legal and compliance teams whether DORA, Swift and PCI DSS apply to each marketing system and data flow.
Insurers hold health, claims, motor, property and life data, and some of it is special category data under GDPR or sensitive personal data under local rules. Marketing use of claims or underwriting information is generally restricted, so segments usually come from product-level or policy-status flags rather than from underwriting detail. Approval intensity depends on the product line, with regulated sales communications, renewal notices and brokered products often needing sign-off from compliance and sometimes from distribution partners. EU insurers are DORA entities, so ICT contracts for marketing platforms fall under the same register and exit requirements as other ICT services. US insurers are generally regulated at the state level rather than under the FTC Safeguards Rule, so confirm which regime applies.
- Data sensitivity: Claims, health and underwriting data should not enter marketing segments, and the team should document which policy attributes are permitted.
- Approval intensity: Renewal, cancellation and product comparison messages often need sign-off, and some require fixed templates from the legal team.
- DORA status: EU insurers must apply DORA to the Mautic hosting, sending service and CRM integrations as ICT services.
- Broker and agent access: Partner-facing campaigns can create extra access and data-sharing paths that must be documented and limited.
- US regulatory regime: US insurers are typically supervised by state regulators, so the FTC Safeguards Rule may not apply directly.
Confirm with your legal and compliance teams which data categories may be used for marketing and which regulator covers each entity.
Wealth managers and asset managers hold portfolio, investment preference, suitability and income data, which many firms treat as among the most sensitive personal data they hold. Marketing often depends on suitability and risk profile, so firms need strict rules about which fields can drive audiences. Approval intensity is high for investment-related content, because communications may be subject to fair presentation and performance rules set by financial regulators. A US non-bank wealth firm under FTC jurisdiction may fall under the FTC Safeguards Rule, which requires multi-factor authentication for any individual accessing any information system unless the Qualified Individual approves an equivalent control in writing. EU-authorized firms are generally in DORA scope.
- Data sensitivity: Portfolio values, holdings and suitability answers should not be copied into marketing contacts, and segments should use approved, coarse attributes.
- Approval intensity: Investment content usually needs documented review and archived versions of every send.
- FTC Safeguards Rule: Non-bank firms under FTC jurisdiction must enforce multi-factor authentication for system access, including the marketing console.
- Access control: Advisors and marketing staff should have role-based access, with logs for exports and segment changes.
- Retention: Sent communications and approvals may need to be kept for periods set by the firm's regulators, so confirm the retention schedule before build.
Confirm with your legal and compliance teams whether the FTC Safeguards Rule, DORA or another regime applies to the firm and its marketing data.
What auditors and regulators ask for, and what produces it
This table maps each item an auditor, examiner or regulator is likely to request for a financial services marketing deployment to the component that produces it. Read the middle column as the artifact to request and the right column as where it lives, since many items are only as good as the logging, backups and identity controls behind them. Confirm the exact evidence expected with your compliance lead and assessor before the build is designed.
| Evidence item | What it shows and why it is asked for | Component that produces it |
|---|---|---|
| Register of ICT arrangements | Lists Mautic, its hosting provider, email sending service, CRM connector and backup provider as contracted ICT services, as DORA Article 28(3) expects | Your third-party risk register, maintained by procurement and compliance |
| Contract clauses on location and exit | Shows where data is processed, notice of changes, data return on termination and a tested exit path, reflecting DORA Articles 28(8) and 30(2) | Signed contracts with hosting and sending providers, plus a documented exit plan |
| Admin access review and change log | Shows who can create, approve or edit campaigns, segments and users, and when rights were reviewed | Mautic user and audit records, exported to central logging, and tickets for each change |
| Approval trail for financial promotions | Shows that each promotion was approved by a named reviewer before the send, and that the approved version is the one sent | Mautic campaign version history, the compliance review workflow and the change ticket |
| Consent and suppression history exports | Shows opt-in, withdrawal and suppression timestamps and sources, which regulators and complaint handlers request | Mautic contact timeline and consent fields, exported on a schedule and compared with the CRM record |
| Retained copies of sent communications | Shows what each customer actually received, the content and the send date, for complaint handling and record retention | Archive of rendered email content stored by the sending pipeline, plus Mautic email logs |
| MFA configuration evidence | Shows that every human login to Mautic requires multi-factor authentication, as the FTC Safeguards Rule requires for covered institutions | Identity provider policy and enrollment reports, with Mautic SSO or the login configuration as proof |
| PCI scope statement | States whether card data or payment fields touch the marketing stack, and confirms that it does not, supporting the scope boundary | Data flow diagram, form field inventory and the network segmentation record, owned by the security team |
| Tested restore records | Shows that the Mautic database and files can be recovered within your stated objectives, not just that backups run | Backup job logs, restore test tickets and dated results from a restore into an isolated environment |
How much work does a regulated Mautic deployment take?
What drives the cost of a regulated Mautic deployment?
The biggest cost drivers are the scope of the approval workflow, the number of integrations, and how much evidence the compliance team needs. Mautic itself has no paid edition, so you pay for the servers, the email sending service, the implementation work, CRM integration, data migration and ongoing administration. Each of these is a separate line in a quote. A larger contact base, more segments and more sending domains add setup and testing effort. Ask any partner to split the quote into one-time build work and recurring costs such as hosting, sending volume, support and upgrades, so you can compare options fairly.
How long does a regulated Mautic rollout take?
The duration depends on how many phases the firm requires and how quickly reviews return, not on Mautic alone. Most regulated rollouts run in sequence: scope and data mapping, hosting and security hardening, consent and suppression design, CRM integration, a review of the approval workflow, and then a controlled pilot send. Each phase can wait on legal, compliance or data owner sign-off. No fixed duration is stated here. Ask your partner for a phased plan in the written scope, with named review gates and the decisions each gate needs.
What must the firm supply before a Mautic project starts?
The firm must supply decisions that only it can make. Legal review needs to confirm the wording of financial promotions and the lawful basis for each audience. Compliance sign-off must approve the approval workflow, retention period for sent communications and suppression rules. Data owners must identify which CRM fields, customer attributes and account data are allowed to reach the marketing platform, and which must stay out. Without named people for each decision, timelines tend to slip, because the implementation team cannot finalize segments, templates or integrations.
Can an internal team run a regulated Mautic deployment alone?
An internal team can run Mautic once it has the skills for PHP application hosting, database administration, mail infrastructure, cron scheduling and CRM integration. The Mautic project states it should not run on shared hosting and recommends a VPS or dedicated server. Mautic also depends on cron jobs for segment updates, campaign updates and triggers, plus a broadcasts command and a messenger consumer for queued email. Check whether your team can operate these components, test changes, and produce the evidence an assessor will ask for. Many firms split the work, keeping day-to-day campaign operations internal and buying implementation and support.
How do Mautic upgrades and LTS windows affect the team?
Upgrades are a recurring workload that regulated teams should plan for in advance. Mautic publishes monthly patch releases, minor releases every three months and major releases every two years. Its stated support windows differ by version: Mautic 7.2 receives security support until 30 September 2026, and Mautic 7.3 is planned as the long-term support release with security support through 31 December 2027. Older versions have earlier end dates. Your team must test each upgrade in a non-production environment, confirm PHP and database requirements, and document the change for change-management review.
Can campaigns be paused for approval before they send?
Yes, but the control must be designed and tested, not assumed. Campaigns can be held in a draft or unpublished state while an approver reviews the content, audience and send schedule. The approval step should be recorded with the approver's identity and time, so the firm can show who approved each financial promotion. Because campaigns and segments run on scheduled jobs, the team must confirm that a paused campaign cannot be triggered by a cron job or a queued send. Ask your partner to demonstrate this with a test campaign before any live audience is connected.
Which compliance evidence will the team need to prepare?
The team should prepare evidence that the controls work as designed. This typically includes the approval workflow records, consent and suppression configuration, retention settings for sent communications, access control records for administrators, change records for upgrades and integration configuration. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue any audit report or attestation. Confirm with your assessor which records they expect and how long they must be kept before the implementation starts.
Who pays for ongoing administration after go-live?
Ongoing administration is a recurring cost, paid either to internal staff or to a support partner under a retainer. Work includes patching, monitoring queues and cron jobs, reviewing suppression lists, handling bounces, responding to erasure or access requests and reviewing approval logs. Ongoing support, upgrades and continuous testing are available as retainers from DeployOpen, and scope is agreed in writing. Ask any partner to list which tasks are included, how response times are defined, and which tasks fall to your team.
What to ask an implementation partner before you hire
Start by asking how the partner maps your obligations to the build. Ask which DORA articles they treat as applicable to your entity, since Article 28(3) expects a register of information on all contractual arrangements for ICT services and Article 30(2) expects the contract to state where data is processed and how it is returned. For the FTC Safeguards Rule, ask how multi-factor authentication is enforced on the Mautic administrative console and any CRM connector, and whether any exception is documented as an equivalent control approved in writing by your Qualified Individual. Ask them to show the mapping as a table you can keep, not a verbal assurance. Confirm with your own counsel which regime applies to your entity before you accept the mapping.
Next, press on the approval and retention mechanics. Ask how a financial promotion is blocked from sending until a named approver signs off, whether that gate is a Mautic workflow step, an external approval tool, or a manual control, and how a changed campaign forces re-approval. Ask how a copy of each sent message, with its segment, send time and version, is retained and where it is stored, and how that retention period is set. For consent and unsubscribe, ask where the record of each opt-in and withdrawal lives, whether suppression is enforced before every send and not only at list import, and how a withdrawal propagates to the CRM. Ask the partner to demonstrate these steps in a test instance using dummy contacts.
On the data side, ask how CRM sync is scoped. The partner should name the exact contact fields passed to Mautic, state that account numbers, balances, card data and income fields are excluded by design, and explain how a field-level allow list is enforced and reviewed. Ask how cron and queue capacity are sized: the Mautic cron jobs documentation calls for staggered runs and a messenger consumer when email is queued, and you should ask for the specific schedule, consumer count and monitoring they will set on your hosting. For upgrades, ask how they track the Mautic release calendar and the security support end dates, which version they will run during your contract, and how the LTS upgrade is tested. Finally, ask what evidence they hand over. DeployOpen prepares evidence for your assessors but does not issue audit reports, attestations or certifications, so ask which independent auditor or assessment body will review that evidence.
