Standards Day Notes
The version of the browser you are using is no longer supported. Please upgrade to a supported browser.Dismiss

Comment only
Still loading...
Slide No.PaperLinkIssueTypeVersionProposalOutcomeNext StepDiscussion (Public)
3Rules and Guidelines Rules and Guidelines part of the IATI StandardRule3.01Rules and guidelines should be included as an integral part of the standard along with the schema and codelists
AcceptNo discussion.
4Rules and Guidelines Rules and Guidelines part of the IATI StandardDefinition3.01A rule is a mandatory condition that cannot be defined in and enforced through the schema but is part of the standard and is validated through a machine-run procedure.
AcceptNo discussion.
5Rules and Guidelines Rules and Guidelines part of the IATI StandardDefinition3.01A guideline is a description of recommended best practice that is implemented where applicable.
AcceptNo discussion.
6Rules and Guidelines Rules and Guidelines part of the IATI StandardAction3.01A new text based Rules section should be added to which will be recognised in Version 3.03 as a definitive part of the IATI Standard
AcceptIt was clarified that rules are not currently enforceable.
7Rules and Guidelines Schedules Guideline2.03The need to produce and maintain an implementation schedule should no longer be a requirement of IATI publishing.Consult furtherThe wording of the proposal needs to change and further discussion on how the information previosly captured in the implementation schedule can added to the IATI Registry. IATI tech team to take forward for further consultation and change wording of this proposal.There was an agreement in the room that the implementation schedule is not widely used. However, if it is removed a suitable alternative should be put in place given that a lot of organisations still need to provide this information.

Some proposals were made making improvements to the IATI Registry that can capture this information.

There were also strong views that the wording of the proposal should be changed as a guideline cannot provide a negative message "should no longer be a requirement", but rather focus on best practice for implementing that change.
7.1Rules and Guidelines Schedules Guideline2.03Publishers should improve and regularly maintain the content of all fields in their IATI Registry publishing accounts.
Consult furtherIt was clarified that the proposal is about the master publisher account on the IATI Registry.

Some points were raised about difficulty in monitoring improvement against this proposal but it was clairifed that the guideline is about encouraging best practice.
8Rules and Guidelines Registry Publisher Status Action?Introduce a new IATI Registry status of ‘Dormant’ for all accounts where no new information has been added within the most recent 12 months.
Consult furtherNew wording to be suggested for the "Publisher Status" that can replace dormant. IATI tech team to take forward for further consultation.Various discussions took place around the proposed duration of 12 months. The majority of participants agreed that 12 months is not sufficient and proposals were made about extending to 15 or 18 months and also setting different rules for old and new organisations.

It was agreed that a better wording for the status should be used and suggestions were welcomed.

Questions were raised about the implications for publishers that have this status and it was clarified that they will only be flagged on the IATI Registry.
9Rules and Guidelines Registry Publisher Status Action?Make the status of ‘Active’ or ‘Dormant’ visible to all
Consult furtherSome questions were raised around the implications of making the status visible to all.

An agreement is required on slide 8 before any further discussion can take place regarding this proposal.
11Rules and Guidelines Registry Publisher Status Action?Amend the highlighted published ‘count’ on the IATI Registry to refer to ‘Active’ publishers.
Consult furtherNo discussion.
13Controlling Data Quality illegitimate item or condition is an invalid item or condition that stops users from processing the data. The definition of what constitutes an illegitimate item is determined from a control list of invalid conditions. Eg: Badly formed and invalid xml; invalid characters; invalid reporting-org/@ref
Consult furtherGenerally there was confusion in the room about specified definitions, as well as the differences between them.

Discussion cut short and later points in section skipped due to lack of clarity and discussion moving onto implementation details.
14Controlling Data Quality invalid item or condition is one that fails validation against the schema, codelists or rules.
Consult furtherSee slide 13
15Controlling Data Quality imperfect item or condition is valid but doesn’t meet a guideline
NoneSee slide 13
16Controlling Data Quality Illegitimate/invalid/imperfect activity is one containing one or more illegitimate/invalid/imperfect items.
NoneSee slide 13
17Controlling Data Quality file (or API endpoint) is illegitimate/invalid if it contains one or more illegitimate/invalid items or activities
NoneSee slide 13
18Controlling Data Quality publisher is illegitimate if either all its files are illegitimate or its registry record is illegitimate
NoneSee slide 13
19Controlling Data Quality ProcessAction-The registry must run full validation on all new and changed files every night and stores the results in the dataset metadata
AcceptIATI tech team to take this action forward.The steps in the validation process were clarified and consensus was reached on this proposal.

No additional comments were raised.
20Controlling Data Quality BehaviourAction-Illegitimate publisher
1) Publisher is flagged in a similar way to the new proposed ‘Dormant’ status
2) Publisher record is not visible on the Registry. Status similar to ‘pending
Consult furtherThere was not concensus about which option to choose.
21Controlling Data Quality BehaviourAction-Illegitimate file - Option One
A dataset record is maintained without a publicly accessible link to the file. The dataset remains visible but flagged in the Publisher’s lists of datasets. The validation report is accessible in the dataset’s metadata.
AcceptSeveral points were raised about invalid rather than illegitimate data.

Suggestion that publishers should be emailed when there is a problem with their data.

Concensus around labelling. Noted that the infrastructure is not currently in place for full implementation involving notifications.
22Controlling Data Quality BehaviourAction-Illegitimate file - Option Two
No dataset record of the file is held. The publisher record maintains a list of illegitimate files. When adding a new file the API returns an error message informing the update process that registration failed.
RejectSee slide 21
23Controlling Data Quality BehaviourAction-Invalid file - Option One
The file is accessible. The file is flagged as invalid in the Publisher’s lists of datasets. The validation report is accessible in the dataset’s metadata.
AcceptConcensus around Option 1. Noted that there are problems around master data management.
24Controlling Data Quality BehaviourAction-Invalid file – Option Two
No dataset record of the file is held. The publisher record maintains a list of invalid files. When adding a new file the API returns an error message informing the update process that registration failed.
RejectSee slide 23.
25Controlling Data Quality BehaviourAction-Imperfect file – Three options
No action
The validation report is accessible in the dataset’s metadata.
The file is flagged as imperfect in the Publisher’s list of datasets. The validation report is accessible in the dataset’s metadata
NoneThis was skipped.
26Controlling Data Quality BehaviourAction-Illegitimate Publisher – Two Options

Publisher is not included, other than on a separate, visible dashboard list
Publisher is included with zero scores
Consult furtherThis was skipped.
27Controlling Data Quality Statistics BehaviourAction-Illegitimate activity
Under both registry options for illegitimate files the activity would not exist and therefore would not be part of the assessment.
NoneThis was skipped.
28Controlling Data Quality Statistics BehaviourAction-Invalid activity – Two Options
1) Activity is counted in the total number of activity but scores zero on all assessments.
2) No action or lesser action. Option one would diminish the granular analysis, for example, of core fields as one missing core field would be interpreted as all core fields being missing.
Consult furtherThis was skipped.
29Controlling Data Quality ScoringAction-A kitemark for IATI compliance?

A three-grade system?
*** - 80% plus score in publisher statistics
** - No invalid or imperfect files
* - No invalid files
Consult furtherNoted that data use is more important than compliance.

Would act as an incentive to increase data quality, rather than the be-all-end-all.

Could act as a badge on top of the Publisher Statistics.

Agreed in principle, with details to be confirmed.
30Controlling Data Quality feedback and support to publishers – Two Options

No active feedback and support
Provide a two level data quality service: * Basic service: automatically inform publishers by e-mail on data quality problems * Premium service: Active support by the IATI technical team on data quality problems for those publishers who paid their membership fees.
Consult furtherMAINTAIN on discuss and then take proposal to members assembly.General support for some sort of tiered support system, with integration into a free-market ecosystem, with basic levels of support involving automated tooling that provides feedback and suggestions for improvement.

Decided that further discussion should be had on Discuss, before passing over to the Members Assembly to make a decision.
32Codelist Management
Embedded and Non-embedded listsDefinition-Embedded codelists contain codes that involve functional logic that impacts on the way in which the standard is interpreted and processed. They are embedded in the standards’ schema
AcceptInvestigate distinction between Embedded, Non-Embeddd and Replicated Codelists.

Look into how to track versions of Codelists.
Agreement on the definitions of the types of Codelist.

May be worth looking into the naming of 'Embedded' and 'Non-Embedded'. Also consider a difference between IATI Codelists and those replicated from elsewhere.

Need to consider how to deal with varying versions of Codelists so that it can be seen when codes are added or removed.
33Codelist Management
Embedded and Non-embedded listsDefinition-Non-embedded codelists contain codes that qualify data, not processes. They may be generated and maintained by third-parties or IATI.
AcceptSee slide 32.
34Codelist Management
Embedded and Non-embedded listsRuleEmbedded codelists can only be changed through the standard upgrade process and are versioned accordingly
AcceptSee slide 32.
35Codelist Management
Embedded and Non-embedded listsGuideline-Non-embedded codelists may be changed at any time subject to appropriate notification and/or consultation and are not versioned
AcceptSee slide 32.
36Codelist Management
Embedded and Non-embedded listsAction2.03Redefine 30 codelists (as per list in paper) from embedded to non-embedded during the 2.03 upgrade process
Consult furtherAccept in principle but check details of which should be movedAgreement on principle.

Need to look through the proposd list to ensure that all should definitely be moved.
37Codelist Management
Embedded and Non-embedded listsAction3.01Move embedded codelists into the schema
AcceptNo discussion.
38Codelist Management
Replication of external vocabulariesAction-Create a new metadata category for Vocabulary Codes , one being ‘replicated’ and the other ‘non-replicated
AcceptIATI should work with WP-STAT and the DAC to provide Codelists in a machine-readable format.

Historical Codelist information available through git could be exposed in a programmatic manner.

Could be useful to maintain a list of IATI org IDs.
39Codelist Management
Replication of external vocabulariesAction-Create a new metadata category for Codelists - Update Frequency
AcceptSee slide 38.
40Codelist Management
Replication of external vocabulariesGuideline-The decision on which codelists should be replicated needs to be a pragmatic one which reconciles the widespread use of a list, the length of the list and the overhead required to keep the list up to date.
AcceptSee slide 38.
41Codelist Management
Replication of external vocabulariesAction-Manually replicated codelists should be updated by the Technical Team in line with the agreed Update Frequency
AcceptSee slide 38.
42Codelist Management
Deprecation of retired codesGuideline-Retired codes should be deprecated but never deleted from codelists maintained or replicated by IATI
AcceptIdeal situation would be a full historical list of historical versions of all Codelists.

Agree in principle, but need to determine details.
43Codelist Management
Shared governance of Organisation Identifier Lists codelistAction3.01The OrganisationRegistrationAgency codelist should be renamed to 'OrganisationIdentifierList'
RejectUnclear why the name of the list needs changing. Maybe the list may contain something other than Registration Agencies in the future.
44Codelist Management
Shared governance of Organisation Identifier Lists codelistAction2.03Maintenance of the OrganisationIdentifierList list should be carried out by the 'org-id project’
AcceptTech Team to look at change management & governance processes.Various forms of clarification that because the list would be managed as other replicated Codelists are, this could be implemented as a decimal. With this clarified, agreed.
45Codelist Management
Codelist mappings Codelist2.03Codelist mappings should refer to a Schema, not a Dataset
AcceptThis would make it easier for developers to build tools that use Codelists.

Deemed to be about back-end-processing, so discussion cut short.

Agreement that this should be a thing among those who understood what was being proposed.
47Upgrade Rules TimetablesRule-Agree that the revised rules, guidelines and timetables for both decimal and upgrades can be submitted to the Members Assembly for adoptionConsult furtherConduct spearate consultation on Discuss ahead of Members Assembly, with a key discussion point of: Are the timescales long enough?Various comments that the timelines in the initial version were too short. Noted that the Tech Team has revised the timescales.

Key point for further consultation: Are the time periods long enough?
49Deprecation of Old Versions Rule-Two years after the introduction of a new integer version of the standard all versions of previous integers will be deprecated
Consult furtherAgreed in principle but timing needs further discussion. Tech Team to look at how Google Transit Feed handles deprecation.No objection to the concept of version deprecation, though need to clarify the process and timescale - somewhere in the region of 2-5 years is the key timeframe to base further discussion around.

Should look into how other standards such as Google Transit Feed handle deprecation.

Noted that automated conversion tools could provide best-effort conversion, though the addition of mandatory fields can be problematic.
50Deprecation of Old Versions of deprecated versions-Publishers are strongly recommended NOT to use deprecated versions
Consult furtherSee slide 49.
51Deprecation of Old Versions of deprecated versions-Activities published in a deprecated version will be penalised according to new data quality guidelines
Consult furtherSee slide 49.
52Deprecation of Old Versions of deprecated versions-The use of deprecated versions within official tools maintained by the IATI Technical Team will be phased out.
Consult furtherSee slide 49.
53Deprecation of Old Versions of deprecated versions-The IATI Technical Team will prioritise help-desk support for data in current (non-deprecated) versions
Consult furtherSee slide 49.
55Hierarchies Activities-Hierarchy activity linkage should be managed by use of the <related-activity> element and @type of 1 (parent) and 2 (child).
AcceptQuestions were raised about how widely hieararchies are used.
56Hierarchies Activities-The ‘sibling’ @type value should be removed
Consult furtherFurther discussion was requested
57Hierarchies types of transactions may be reported at any level provided that:
There is no double counting within a hierarchical group of activities.
Transactions should not report disbursements within a hierarchical group. The flow of money down a hierarchical chain is implicitly assumed
Incoming Funds can be present at any level but must be reported only once and at only one level
AcceptThere was a wider discussion in the room around different use of hierarchy, described as hierarchy of relationship as well as hierarchy of funding flows. However, there was confusion around the definition being used for double counting and how that relates to reporting hierarchies. It was clarified that as long as the flow of resources is reported correctly, there will be no double counting. However, a number of examples were given from organisations highlighting that that there is inconsistency in how they use hierarchies and their understanding of double counting.
58Hierarchies & results can be defined at any number of levels
AcceptNo discussion.
59Hierarchies mandatory and any other fields should be present at all levels. This therefore means that it may be necessary to repeat the same information at all levels.
AcceptThe case of documents was mentioned and it was explained that they are not a mandatory field. It was suggested that the use of "any other fields" in this proposal should be clarified.
60Hierarchies scope of use must not extend beyond the reporting of the activities of a single organisation.
AcceptA point was made by an organisation that there might be cases where an organisation might like to link to an activity of an another organsiation even if there is no transacation. A proposal was made about potentially adding a new related activity type.
60.1Hierarchies Statistics-Hierarchical groups should be treated as a single activity for the purpose of publisher statistics assessmentsNoneThere was no disagreement to this suggestion, but it requires further consultation as it was introduced during the discussion.
62Traceability guidelinesGuideline-Incoming funds and commitments transactions must contain provider-activity-id where the funds are received from an IATI reporting institutionAcceptWhile not specifically related to this proposal, question was raised about the possibility of adding incoming commitments.
63Traceability guidelinesGuideline-Transaction types ‘Disbursement’ and ‘Expenditure’ should be used in accordance with the descriptions in the Transaction Type codelist. i.e. Disbursements are made to recipients who should also be required to report their activities to IATI. The recipients of expenditures fall outside of IATI traceability standardsAcceptThere seemed to be a consensus it the room about this proposal but it was pointed put that the definition of disbursement and expenditure can be better explained. There was discussion around the specific wording being used in this proposal and a suggestion to change it from "required to report activity to IATI" to "will be expected to report activity to IATI". It was clarified that this proposal is about a guideline.
64Traceability guidelinesGuideline-Incoming funds and commitments transactions should contain provider-org details where the funds are received from a non-IATI reporting institutionAcceptIt was suggested that for better data use, provider org should provide full name and more elaborate description. It was also proposed that a common terms is used for organisations that are unable to disclose this informaton.
65Traceability guidelinesGuideline-Disbursements should contain receiver-org details and/or receiver-activity-id wherever possibleAcceptIt was highlighted that the wording in this proposal should be made consistent with the previous slide (slide 64).
67Double Counting guidelinesGuideline-There must be no double counting within a single publisher's activitiesAccept
68Double Counting guidelinesGuideline-Secondary publishers must be excluded from any attempt to aggregate IATI data. Wording of the reporting-org/@secondary-reporter documentation should be changed to reflect thisNoneBetter user guidance needs to be provided for secondary publishers.It was agreed that this proposal should be worked out seperately and better user guidance should be provided for secondary publishers to avoid double counting.
69Double Counting guidelinesGuideline-Use traceability guidelines to describe, and therefore cancel out activity or transaction duplication. Where an activity reports incoming funds that come from a disbursement reported elsewhere in IATI data, the disbursement should not be countedNoneSee above
70Double Counting guidelinesAction-Create a dedicated guidance page on this topic, informed by answers to the consultation questions below.AcceptAs double counting cannot be avoided in the IATI standard, the proposals for better guidance on the topic was welcomed by everyone. Following explanation of what is considered as double counting in IATI terms, it was suggested that the definition of double counting is made clearer and the following wording is added "following hiearachy and traceability guideline".
72Core Funding fundingSchema2.03Use activities with clearly defined aid-type (to be discussed under activity standard) to reflect core funding. This can also apply to other sources of income.Consult furtherFurther discussion is required.There was discussion on whether core funding should be handled under the activity or organisation standard with opposing view in the room. Trust funds were brought into the discussion on this proposal but was agreed that they should not be considered under this proposal.Overall, it was agreed that this should be discussed further with specific proposals being worked out, involving more multilateral organisations that can share their experience.
73Core Funding fundingSchema2.03Mirror the <total-expenditure> structure for income, allowing for the reporting of income sources such as mass fundraising, crowdsourcing, private donations, core support funding from donors etc.Consult furtherNo discussion.
75HumanitarianMiscellaneous Humanitarian issues-NoneContinue discussion on IATI Discuss. There was discussion about how the IATI standard can meet the needs for both development and humanitarian aid. It was agreed that to understand the impact of the proposals being made further discussions should take place and everyone were encouraged to contribute to the IATI Discuss forum.
77Results Results IssuesSchema2.03Change cardinality of target and actual elements from 0..1 to 0..*NoneAs the proposals for this section were submitted late it was decided to defer substantive discussion to the 2.03 consultation
78Results Results IssuesSchema2.03Change all results value attributes to optionalNoneNo discussion.
79Results Results IssuesCodelist2.03Add qualitative code to IndicatorMeasure codelistNoneNo discussion.
80Results Results IssuesCodelist2.03Add indicator lists to IndicatorVocabulary codelist per StandardisedIndicators worksheet.NoneNo discussion.
81Results Results IssuesSchema2.03Add optional aggregation-status attribute to indicator elementNoneNo discussion.
82Results Results IssuesSchema2.031) Add optional iso-date attribute to baseline element
2) Add location and dimension elements (0..*) to baseline element
3) Change baseline element cardinality to 0..*
NoneNo discussion.
83Results Results IssuesSchema2.03Add participating-org element as a sub-element of result and indicator elementsNoneNo discussion.
85Common Standard SyntaxRule3.01Enforce all URL.s to be absolute, not relativeAcceptLook into implementing as a Guideline in 2.03This could be implemented as a Guideline so that it is not necessary to wait for 3.01.
86Common Standard Identifier SyntaxSchema3.01Enforce use of uppercase for organisation identifiers (and registration agency suffixes)Consult furtherGeneral agreement that there should be case-sensitivity.

Less agreement around requiring upper-case. There are several problems around backward-compatibility.
87Common Standard identifier syntax / u.r.l encodingSchema3.011) Do nothing but enforce proper url encoding on all urls
2) Restrict character set using Regex
Consult furtherTech Team to look into why Option 1 may cause people problems.Majority of persons in favour of Option 1. A couple of people favour option 2.

Character encoding is a problem that has been solved. Need more investigation into the actual reasons why standard methods of character coding cannot work.

Noted that if Option 2 selected it would be a challenge to get all publishers to follow the rule. There will also be old data, so it wouldn't solve the root problem.
88Common Standard Booleans to be reported as 0/1 NOT false/true. RejectXML already specifies what a valid value for a boolean is (1, 0, true, false). IATI shouldn't redefine this.
89Common Standard encodingGuideline2.03IATI files should use UTF-8 character encodingRejectXML parsers should be able to handle varied character encoding. If they cannot, they're not a good parser.

This is a non-issue.
90Common Standard elementSchema3.01Make root elements mandatory AcceptThis was not required from the start to allow for files to be made up of lots of separate parts. Nobody actually does this.
91Common Standard applicationSchema and Codelist2.03Add attribute iati-activities/@publisher-app
Add attribute iati-organisations/@publisher-app
Add new non-embedded codelist PublisherApplication
Consult furtherTech Team to investigate options further.Multiple tools can be used in the generation process, so this should be an element rather than an attribute. Is also metadata, so may want to sit in the Registry.

May want to look at browser user agents (though the use cases are different).

Agree that the information would be useful, though more research needs to be undertaken.
92Common Standard ratesGuideline2.03Monetary values should, wherever possible, be reported in the primary currency in which the reporting organisation accounts for its operationsConsult furtherConsider how to best deal with specifying exchange rates.Exchange rates caused problems in Bangladesh AIMS. More consultation is required to consider the inclusion of specific exchange rates.
93Common Standard on valid XMLGuideline2.03Change the guidance on structured data to read:
Format - IATI data must be formatted correctly as well-formed XML
Valid - IATI data must pass the relevant IATI schema validation
Rules - IATI data must satisfy the relevant Ruleset that provides additional conditions and logic
AcceptThis is guideline documentation.

Approved with no objections.
94Common Standard percentages should be specified to be inclusive of boundary valuesAcceptNo objections.
95Common Standard all definitions of @xml:lang to:
“A code specifying the language of text in this element.It is recommended that only codes from ISO 639-1 are used. …”
AcceptExpands permitted values under IATI to the full range of values permitted by BCP 47.

Suggests as a Guideline that a subset is used. Does not prohibit use of ISO 639-2 or locale subtags.
96Common StandardNoneDocument-link DescriptionSchema2.03Add a description (with narrative) sub-element to all document-link elements AcceptNo objections.

Clarification that the element would be optional.
98Organisation Standard funding-Discussion in separate paper. See slide 73Consult further
99Organisation Standard operational expenditureSchema2.03Add total-operational-expenditure element With sub-elements: period-start period-end value narrative document-link as already used in other monetary complex elementsAcceptThis proposal arises from the need to capture publishers operational spending in a sustainable way.

Confirmation was sought (and received) that this element would relate to retrospecive spending.

Suggestion that it should be made clear in the guidance that this refers to operational expenditure related to development.

Further consultation is required to better define or advise what is meant by 'operational expenditure'
100Organisation Standard typeSchema2.03Add a budget-type attribute to the following elements:
Consult furtherGo back to Discuss to explore in more detail.Seems to be a new issue that few people are aware of.

User need is unclear.

Organisations have different types of budget.
101Organisation Standard typeCodelist2.03Add a BudgetType codelist with values
1 - Commitment-based
2 - Disbursement-based
Consult furtherSee slide 100
102Organisation Standard typeSchema2.03If no budget-type attribute is specified a commitment-based budget type is assumed.Consult furtherSee slide 100
103Organisation Standard non-flow dataSchema2.03Add crs-nonflow element with five attributes
year (for which the data applies)
Consult furtherBill to lead on determining whether IATI needs to be fully compatible with the CRS.Is required if IATI is to be fully compatible with the CRS.

General consensus that the element is not needed. Cannot make a decision without determining whether IATI should be fully CRS-compatibile.
106Activity Standard publishersSchema2.03Modify definition of reporting-org/@secondary-publisher
“A flag indicating that the reporting organisation of this activity is acting as a secondary publisher. A secondary publisher is one that reproduces data on the activities of an organisation for which it is not directly responsible. This does not include a publisher officially assigned to report on behalf of another.”
Consult furtherThere was confusion about what is meant by the term 'secondary publisher'.

The use of the term 'proxy' was suggested to clarify where publishers report 'officially' on behalf of another organisation. (eg Swedish SIDA amd Ministry of Foreign Affairs)

Further consultation required.
107Activity Standard publishersSchema2.03Add attribute reporting-org/@secondary-unique
“A flag indicating that this activity, reported by a secondary reporter, is not reported to IATI by a primary publisher and can therefore be expected to be unique.”
Consult furtherFor discssion, see above
108Activity Standard publishersSchema2.03Add a code to OrganisationRole codelist used by participating-org
5 – Owner (?)
Consult furtherFor discssion, see above
109Activity Standard Add attribute transaction/transaction-date/@advance-instruction
2. A flag indicating that the transaction date, at the time at which the transaction was first published, is legitimately a future date.
Consult furtherStrong argument that this is an edge case that should not be included.

But no final consensus.
110Activity Standard date must not be in the future, unless @advance-instruction flag is set in which case transaction must not be more than 30 days into the future.Consult furtherDetermine whether any rules need to be undo'd following this decision.See above
111Activity Standard date – Two Options
1. Make transaction/value/@value-date mandatory (for each occurrence of transaction)
2. Change definition of transaction/value/@value-date. “The date to be used for determining the exchange rate for currency conversions. If not present the value of transaction/transaction-date/@iso-date is assumed.”
AcceptConsensus on Option 2. Option 1 rejected
112Activity Standard description of TransactionType “Interest Repayment” to “Interest Payment”AcceptNo objections.
113Activity Standard to TransactionType codelist. 12 - PledgeAcceptNeed 'Incoming Pledge' as well as 'Pledge'.
114Activity Standard Channel of DeliverySchema or Codelist2.03Two options
1) Codelist: Expand the OrganisationType codelist (through both additions and modifications in definitions) to contain all the generic CRS codes. (NB that the numbering of the codes would not align, but could be cross-mapped)
2) Schema: Add attribute participating-org/@channel-code
Consult further