FiDAViSta Format

FiDAViSta (Financial Data Exchange Unified Standard) is an XML-based data exchange standard for payment orders, used by banks and accounting/ERP systems mainly in Latvia. Paysera Payment Import accepts FiDAViSta 1.01 payment files.

Overview

FiDAViSta format is a structured XML format that provides:

✅ XML-based structure - Industry-standard hierarchical format
✅ Multiple data groups - Header, Payments, Statements, Payment Status
✅ Accounting system support - Exported by accounting and ERP systems that implement the standard
✅ Payment numbers - Each payment keeps its DocNo as the Paysera transfer number
✅ Multi-currency support - International payment capabilities

---

File Structure

A FiDAViSta file consists of a FIDAVISTA root element containing several optional groups:

<?xml version="1.0" encoding="UTF-8"?>
<FIDAVISTA>
  <Header>...</Header>
  <Payment>...</Payment>
  <Payment>...</Payment>
  <PmtStat>...</PmtStat>
  <Statement>...</Statement>
</FIDAVISTA>

Root element name

The root element must be named exactly FIDAVISTA (upper case, no namespace prefix). A file with any other root element name is rejected on upload with the error invalid_file_content ("The file content is not consistent with the format.").

Main Elements

Element	Purpose	Status
Header	File metadata and preparation info	✅ Accepted (not used by the import)
Payment	Payment order information	✅ Available
PmtStat	Payment status tracking	🔜 Coming soon
Statement	Bank account statements	🔜 Coming soon

---

Import Rules

These rules apply to every FiDAViSta file uploaded through Payment Import:

Rule	Details
One payer account per file	All <Payment> elements must use the same Paysera account in PayAccNo. The account may be given as its IBAN or as its Paysera account number (EVP...). A file with payments from two different accounts is rejected with invalid_account_data.
At most 500 payments per file	A file with more payments is rejected with transfer_limit_exceeded. Split larger batches into several files.
One <BenSet> per <Payment>	Only the first <BenSet> of each <Payment> is imported. Any further <BenSet> elements are ignored without an error. Create a separate <Payment> for every beneficiary.
Amount, priority and charges live in <BenSet>	Amt, Priority and Comm are read only from inside <BenSet>. If they are placed directly under <Payment>, the upload is accepted but the import fails in the background with transfer_amount_not_positive, because the amount is read as empty.
Charge type	Comm accepts OUR or SHA only (case-insensitive). A missing or empty Comm does not fail the import: the transfer is stored without a charge type and is routed and priced as SHA. BEN or any other value fails the whole import with CODE_UNSUPPORTED_CHARGE_TYPE and no payment from the file is created.
Priority	Only the exact value N creates a normal transfer. Any other value (U, X, lower-case n, an empty or missing Priority) is processed as urgent.
Payment date	A RegDate that is missing, in the past, or not in YYYY-MM-DD format is replaced with today's date. A future date is kept as the payment date; a date more than two years ahead fails the import with TRANSFER_OPERATION_DATE_INVALID.
Validation failures	Payments are validated as one batch. If any payment fails validation, the whole import fails and the errors name the transfer_index of the invalid payments (the first five).

---

Header Element

The Header contains file preparation metadata. The import accepts the Header but does not use it; the file may also omit it.

Fields

Tag	Length	Type	Required	Description
Timestamp	17	xs:string	Optional	Format: YYYYMMDDHHMMSSsss Example: 20231215143025000
From	0-70	xs:string	Optional	Preparer's identifier
Extension	-	ExtensionType	Optional	Additional custom elements

Example

<Header>
  <Timestamp>20231215143025000</Timestamp>
  <From>ACCOUNTING_SYSTEM_ID</From>
</Header>

---

Payment Element

The Payment element contains one payment order. The payer data is given directly under <Payment>; the amount, priority, charge type and beneficiary data are given inside a single <BenSet> element.

The Required column below describes what the Paysera import needs. Fields marked Not used are accepted so that files exported by standard-compliant software import without changes, but they have no effect on the created transfer.

Core Payment Fields

Tag	Length	Type	Required	Description
ExtId	0-10	SwiftString	Optional	Unique payment ID in external system. Not used by the import.
DocNo	1-10	SwiftString	Mandatory	Payment/document number. Becomes the transfer number.
RegDate	10	xs:date	Optional	Payment date (YYYY-MM-DD). See Import Rules for how past, missing and future dates are handled.
TaxPmtFlg	1	xs:string	Optional	Y = Tax payment N = Normal payment Not used by the import.
Ccy	3	CurrencyType	Mandatory	Payment currency (EUR, USD, etc.)
PmtInfo	0-140	EksString	Optional	Payment description (transfer details)
BankInfo	0-140	xs:string	Optional	Information for the bank. Not used by the import.

Payer Fields

Tag	Length	Type	Required	Description
PayLegalId	0-20	LegalIDType	Optional	Payer's registration/personal ID. Defaults to the code of the account owner.
PayAccNo	1-34	AccountMType	Mandatory	Payer's Paysera account: its IBAN or its Paysera account number (EVP...). Must be the same in every payment of the file.
PaySubAccNo	0-34	AccountOType	Optional	Payer's sub-account. Not used by the import.
DebitCcy	3	CurrencyType	Optional	Debited currency. Not used by the import. The transfer is always made in Ccy.

Beneficiary Set (BenSet)

Exactly one <BenSet> per <Payment>. The standard order of the elements is BenExtId, Priority, Comm, Amt, then the beneficiary and bank fields; the import does not depend on the order.

Tag	Length	Type	Required	Description
BenExtId	0-5	SwiftString	Optional	Beneficiary ID in the external system. Not used by the import.
Priority	1	xs:string	Optional	N = Normal U = Urgent X = treated as Urgent Case-sensitive. Mandatory in the standard, but the import does not require it: a missing or empty value is processed as Urgent.
Comm	3	xs:string	Optional	OUR = Payer pays SHA = Shared Mandatory in the standard, but the import does not require it: a missing or empty value is stored as no charge type and the transfer is routed and priced as SHA. BEN is not supported and fails the import.
Amt	1-12	AmountType	Mandatory	Amount with decimal point (e.g., 1000.50)
BenAccNo	0-34	AccountOType	Mandatory	Beneficiary's account. An IBAN is detected automatically.
BenSubAccNo	0-34	AccountOType	Optional	Beneficiary's sub-account. Not used by the import.
BenAccIbanFlg	0-1	xs:string	Optional	Y/N IBAN flag. Not used by the import (IBANs are detected automatically).
BenName	1-105	EksString	Mandatory	Beneficiary's name
BenLegalId	0-20	LegalIDType	Optional	Beneficiary's registration/personal ID
BenAddress	0-70	EksString	Optional	Beneficiary's address. Not used by the import.
BenCountry	2	CountryType	Conditional	ISO 3166-1 alpha-2 country code (e.g., LT). Mandatory when BenAccNo is not an IBAN; for an IBAN the country is taken from the IBAN.
BudgCode	0-10	SwiftString	Optional	Budget revenue code. Not used by the import.

Beneficiary's Bank

These elements are also placed inside <BenSet>.

Tag	Length	Type	Required	Description
BBName	0-35	EksString	Optional	Bank name
BBAddress	0-70	EksString	Optional	Bank address. Not used by the import.
BBSwift	8-11	SWIFTType	Conditional	Bank SWIFT/BIC code. Optional when BenAccNo is an IBAN (the BIC is resolved from the IBAN); provide it for non-IBAN accounts.
BBCode	0-66	BankCodeType	Optional	Bank code (with CodeType attribute)

Intermediary Bank

Accepted inside <BenSet> for compatibility with the standard, but not used by the import.

Tag	Length	Type	Required	Description
CBAcc	0-34	AccountOType	Optional	Correspondent account
CBName	0-35	EksString	Optional	Intermediary bank name
CBSwift	8-11	SWIFTType	Optional	Intermediary SWIFT code
CBCode	0-66	BankCodeType	Optional	Intermediary bank code

AMK Set (Balance Code)

Accepted inside <BenSet> for compatibility with the standard, but not used by the import.

Tag	Length	Type	Required	Description
Opc	1-3	xs:string	Optional	AMK balance code (digits only)
Amt	1-12	AmountType	Optional	AMK code sum

---

Data Types

Standard Types

Type	Min	Max	Format	Description
xs:string	0	∞	Unicode	Standard XML string
xs:date	10	10	YYYY-MM-DD	Standard XML date
xs:decimal	-	-	0-9.	Decimal number

Custom Types

Type	Min	Max	Characters	Description
SwiftStringType	-	-	0-9 A-Z a-z /-?:().,'+	SWIFT X character set
EksStringType	-	-	0-9 A-Z a-z A-Ž /-?:().,'+	Extended with Latvian/Latin
SWIFTType	8	11	A-Z 0-9	SWIFT/BIC code
CurrencyType	3	3	A-Z	ISO currency code
AmountType	1	12	0-9.	Amount (12 digits, 2 after decimal)
AccountMType	1	34	SwiftString	Mandatory account
AccountOType	0	34	SwiftString	Optional account
LegalIDType	0	20	SwiftString	Legal/personal ID
BankCodeType	-	-	SwiftString	Bank code with CodeType attribute
CountryType	2	2	A-Z	ISO 3166-1 alpha-2

---

Example: Simple Payment

A normal-priority EUR payment to an IBAN. Replace PayAccNo with your own Paysera account; the account numbers below are the published IBAN registry examples for Lithuania and Latvia.

<?xml version="1.0" encoding="UTF-8"?>
<FIDAVISTA>
  <Header>
    <Timestamp>20231215143025000</Timestamp>
    <From>ACCOUNTING_SYSTEM</From>
  </Header>
  <Payment>
    <ExtId>PAY001</ExtId>
    <DocNo>INV2023001</DocNo>
    <RegDate>2023-12-15</RegDate>
    <TaxPmtFlg>N</TaxPmtFlg>
    <Ccy>EUR</Ccy>
    <PmtInfo>Payment for services</PmtInfo>
    <PayAccNo>LT121000011101001000</PayAccNo>
    <BenSet>
      <Priority>N</Priority>
      <Comm>OUR</Comm>
      <Amt>1000.50</Amt>
      <BenAccNo>LV80BANK0000435195001</BenAccNo>
      <BenName>John Smith</BenName>
      <BenAddress>Main Street 123, Riga</BenAddress>
      <BenCountry>LV</BenCountry>
    </BenSet>
  </Payment>
</FIDAVISTA>

---

Example: International Payment with SWIFT

An urgent USD payment to a non-IBAN account, so BenCountry and BBSwift are required.

<?xml version="1.0" encoding="UTF-8"?>
<FIDAVISTA>
  <Header>
    <Timestamp>20231215143025000</Timestamp>
    <From>ERP_SYSTEM</From>
  </Header>
  <Payment>
    <ExtId>INT001</ExtId>
    <DocNo>INTL2023001</DocNo>
    <RegDate>2023-12-15</RegDate>
    <TaxPmtFlg>N</TaxPmtFlg>
    <Ccy>USD</Ccy>
    <PmtInfo>International consulting fee</PmtInfo>
    <PayAccNo>LT121000011101001000</PayAccNo>
    <BenSet>
      <Priority>U</Priority>
      <Comm>SHA</Comm>
      <Amt>5000.00</Amt>
      <BenAccNo>000123456789</BenAccNo>
      <BenName>ACME Corporation Ltd</BenName>
      <BenAddress>456 Broadway, New York, NY 10013</BenAddress>
      <BenCountry>US</BenCountry>
      <BBName>Citibank N.A.</BBName>
      <BBAddress>399 Park Avenue, New York</BBAddress>
      <BBSwift>CITIUS33</BBSwift>
    </BenSet>
  </Payment>
</FIDAVISTA>

---

Payment Status Element (PmtStat)

Coming Soon

Payment status functionality will be available soon. This element tracks payment execution status.

Planned Fields

Tag	Description
ExtId	Reference to payment ID
BenExtId	Reference to beneficiary ID
BankRef	Bank reference number
StatCode	Status: E (Executed), R (Revoked), P (Processing), O (Other)
BookDate	Execution date
InfoToCustomer	Status explanation/error message

---

Statement Element

Coming Soon

Account statement functionality will be available soon for storing bank account statements.

---

Key Features

Priority Levels

Code	Name	How the import processes it
N	Normal	Standard processing
U	Urgent	Urgent processing
X	Express	Processed as Urgent (no separate express handling)

The value is case-sensitive. A missing or empty Priority is processed as Urgent.

Commission Types

Code	Name	Who Pays	Supported
OUR	Payer	All fees paid by payer	✅
SHA	Shared	Fees split between parties	✅
BEN	Beneficiary	All fees paid by beneficiary	❌ Fails the import with CODE_UNSUPPORTED_CHARGE_TYPE

The value is case-insensitive. A missing or empty Comm is accepted: the transfer is stored without a charge type and is routed and priced as SHA.

Tax Payment Flag

Code	Meaning
Y	Tax payment
N	Normal payment

The flag is accepted but does not change how the payment is processed.

---

Best Practices

✅ DO

• Use proper XML encoding (UTF-8)
• Use FIDAVISTA as the root element
• Put Priority, Comm and Amt inside <BenSet>
• Use one <Payment> per beneficiary
• Specify correct currency codes
• Use IBAN format when possible
• Include SWIFT codes for non-IBAN international transfers
• Use OUR or SHA as the charge type

❌ DON'T

• Use invalid XML characters
• Exceed maximum field lengths
• Mix payments from different Paysera accounts in one file
• Put more than 500 payments in one file
• Use BEN as the charge type
• Use incorrect date formats
• Omit BenCountry for non-IBAN accounts

---

FiDAViSta vs Other Formats

Feature	FiDAViSta	MOKESIS	TARESIS
Format	XML	TAB-separated	TAB-separated
Complexity	High	Medium	High
Fields	Variable (XML)	31 fields	40 fields
System	Latvian accounting/ERP standard	General	International
Tracking	DocNo (transfer number)	Payment numbers	Payment numbers
Status	Planned (PmtStat)	Separate	No
Validation	Structure check on upload	Manual	Manual
Best for	ERP integration	General use	International

---

Integration Workflow

FiDAViSta files are typically produced by:

• Accounting systems that export the FiDAViSta standard
• ERP systems with a FiDAViSta export
• Banking systems supporting the FiDAViSta standard
• Financial management software

Integration Steps

1. Generate XML from your accounting or ERP system
2. Check that the file follows the Import Rules above
3. Export the payment file
4. Import it through Payment Import
5. Track status via PmtStat (when available)
6. Reconcile using Statement (when available)

---

Schema Validation

Paysera does not validate FiDAViSta files against an XSD schema. The upload checks that the file is well-formed XML with a FIDAVISTA root element, and then validates the individual payments.

The xmlns:xsi and xsi:noNamespaceSchemaLocation attributes on the root element are optional and ignored. Files exported by standard-compliant software that carry them are imported normally:

<FIDAVISTA xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:noNamespaceSchemaLocation="fidavista_v0001.xsd">

---

When to Use FiDAViSta

✅ Use FiDAViSta when:

• Your accounting or ERP software exports FiDAViSta files
• You need XML-based integration
• You require payment status tracking (when available)
• You need ERP system integration

❌ Use other formats when:

• Manual payment entry needed → XLS
• Simple bulk imports → MOKESIS
• Complex international routing → TARESIS
• No FiDAViSta export available → MOKESIS or XML

---

Support

Need help with FiDAViSta format?

• 📧 Email: support@paysera.com
• 📞 Phone: Contact Information
• 📚 FiDAViSta standard: consult the FiDAViSta 1.01 specification or your accounting software's export documentation

---

Next Steps

• MOKESIS Format → - Simpler alternative
• TARESIS Format → - International transfers
• XML Format → - Generic XML format
• View all formats → - Return to overview