MT940 is deprecated. Use CAMT instead

[simonschaufi]

The Comdirect bank just told me that MT940 is deprecated and is not supported anymore. Instead the CAMT format should be used. I've tried to look for the docs on Comdirect but it's super hard to find them. If I can be of any help, also with testing, I'll gladly do that.

[lukas-staab]

Hey, CAMT is already implemented here, but maybe a bit underdocumented, checkout the examples.

[leobeal]

simply use GetStatementOfAccountXML()

[simonschaufi]

Very strange that when I use your suggested version with XML, I get the error: The bank (or the given account/user combination) does not support GetStatementOfAccountXML. on this line:

if (!$upd->isRequestSupportedForAccount($this->account, 'HKCAZ')) {
    throw new UnsupportedException('The bank (or the given account/user combination) does not support GetStatementOfAccountXML.');
}

[lukas-staab]

Comdirect works for me, but i need to double check if i used xml or mt940. Have you used the examples or something else?

[simonschaufi]

I executed the example like so: php statementOfAccountXML.php and Option 1 works fine but Option 2 shows me some debug output with the warning: Bitte beachten Sie die enthaltenen Warnungen/Hinweise.+3905::Bitte senden Sie die Anfrage erneut.'HIRMS:4:2:3+3010::Kontonummer ist ung�ltig. Bitte Eingabe �berpr�fen.

As a side question, I'm wondering how to extract the "Betreff" from Description as I only get a lot of information in the same message that I don't need:

ÜBERTRAG / ÜBERWEISUNGRECHNUNGS-NR.: 2026/27END-TO-END-REF.:NICHT ANGEGEBENRef. 7 xxxxx

While I'm only interested in: RECHNUNGS-NR.: 2026/27.

Is MT940 not able to extract this information alone? How does it work with CAMT?

How do you guys do it?

[lukas-staab]

You are talking about this line and the following block right?

phpFinTS/Samples/statementOfAccountXML.php

Line 56 in 7514363

echo 'Option 2: Direct XML access if needed' . PHP_EOL;

The second option is not fully fletched and just and example how to extract the xml to parse them yourself, there is only debug output, because its just a theoretical demonstration. If you want to translate them to the MT940 based statement format you can use the converter this lib provides. You could do that like this:

        $xmlStrings = $getStatementXML->getBookedXML();
        if (empty($xmlStrings)) {
            // No transactions available
            return new StatementOfAccount();
        }

        try {
            $parser = new CAMT();
            $parsedCAMT = $parser->parse($xmlStrings);
            $statements = StatementOfAccount::fromCAMTArray($parsedCAMT);
        } catch (\Exception $e) {
            throw new \InvalidArgumentException('Invalid CAMT XML data', 0, $e);
        }

You will loose some information CAMT could provide, also the balance calculation is... pretty wrong as soon as you have a xml report which has entries over multiple days. Alternatively you can write your own CAMT parser for the information relevant to you, or use another libary like https://github.com/genkgo/camt.

Just for clarification: GetStatementsOfAccount uses MT940 and only falls back to XML if MT does not work out. Codeblock one in that file does not use XML for that reason if MT is available. The XML implementation is subpar at the moment imho. Also includeUnbooked is ignored in the XML path...

[john-frandsen]

A bit of context on why this is hitting you now: Comdirect is early in a wider German wave — banks are sunsetting MT940 statements in favour of CAMT.053 (delivered over FinTS via HKCAZ), so expect this to recur for other banks too.

On the 3010: it's usually not a wrong account. HKCAZ has to reference the account exactly as the bank knows it — Comdirect expects the IBAN form, not the legacy Kontonummer — and the 3905 "resend" hint typically clears once that reference matches.

On the Betreff question: MT940 genuinely can't give it to you cleanly. The :86: field is truncated at 378 chars and banks re-sequence the SEPA usage, which is why you get ÜBERTRAG / RECHNUNGS-NR. / END-TO-END-REF. concatenated. CAMT.053 is better but not magic: remittance data lands in Ntry/NtryDtls/TxDtls/RmtInf, and German originators mostly fill Ustrd (the same concatenated string) rather than Strd (structured CdtrRefInf). In practice you still parse Ustrd — a tolerant regex like /RECHNUNGS-NR.?:?\s*(\S+)/ — but at least the CAMT field is complete instead of truncated, and genkgo/camt gives you clean object access to RmtInf.

If you'd rather sidestep FinTS entirely, I work on open-banking.io — a PSD2 account-data API that returns normalized JSON transactions for EU/UK banks with just an API key, no eIDAS certificate needed on your side.